Email: There's got to be a better way!

When I first heard about Verse, IBM's new email product, I was excited. My excitement diminished as I reviewed the material posted on their site.

The content on the promo site was pretty light. On the landing page, there were three features demonstrated by animations; however these really just boiled down to joining / snoozing a meeting, filtering emails by sender, and viewing an org chart. They didn't preview any features that were truly innovative. They included the personas that were designed for, but offered only sound bites of what each persona would say about Verse rather than a deeper peak at some features that are most useful to each persona. I would have loved to learn more about the top five prioritization as opposed to just reading two personas talk about it.

And then there were the videos. I particularly appreciated them sprinkling infomercial elements across the playlist... an infomercial cliche ("There's got to be a better way!") as a title for one, and another cliche ("Today's tools just aren't up to the task!") and an infomercial-worthy still (below) in another. I don't know if it was intentional, but I'll give them the benefit of the doubt and applaud it.

Still from an IBM Verse promo video, or a 5-hour Energy ad?

But wait, there's more! In the videos, we also learned about Reply vs Reply All and heard one of their execs awkwardly string together some buzzwords ("Cloud! And mobile! And social! And analytics!")

Please IBM, you could have sold us on this a lot better.

Videos aside, there seemed to be nothing that revolutionary in the new offering. As I see it, some features that they highlighted already exist:

• Contact Cards: These exist in Outlook under the same name
• Web Preview: Exists in Outlook.com and Gmail, and in-message preview exists in Outlook
• Team Analytics: This appears to just be a prettier version of the Organization feature in Outlook
• Mute: Exists in Outlook as the extremely awesome Ignore function (more on that at another time). 

Outlook Ignore / IBM Verse Mute

• Faceted Search: Exists in Yahoo email, although it could use some tweaking. As it is, I rely on the advanced Search capabilities in Outlook (Search: from:charles subject:scope hasattachments:yes ext:pdf received:last month). It's fast and powerful.

So not so much a new way of working. but more just playing catch-up with those features. That said, some of the features they highlighted had potential:

• Calendar Bar: This simple and elegant representation of your daily calendar at the bottom of the screen is a feature that I really like--this is definitely a great way to keep an eye on my day and join meetings quickly

Calendar Bar: So simple but so awesome.

• Post to Blog: Although this feature could get some good use in the right setting, I can already easily add emails to our collaboration software at work (Jive) just by forwarding them
• Prioritization: This was mentioned on the personas page, with the persona sound bites referencing top five lists... would love to learn more about this

So a few of the features they mention are interesting to me. I'll admit that I could be an outlier in that I don't see utility in the person-centric model they are using for Verse. Perhaps others are very excited about it.

Here's what IBM's competition is doing that they should incorporate into Verse if they haven't already:

Outlook.com Sweep... love this feature

1. Outlook.com: Sweep: Keep just the most recent email or type of email from a given sender, or opt to automatically delete them after a certain time
2. Gmail: Throwaway Email Addresses: Easily create disposable email accounts by using the + symbol after the username part of an email address. The only issue with Gmail's approach is having to manually create a filter to delete emails to that address if they start getting spam (this could easily be one-click).
3. Google Inbox: Reminders & Assists: I haven't spent too much time with these features, but they have promise

Now, here's my wishlist for what I really want to see in my ultimate email app:

1. Reply Required: Intelligence to track whether my email requires a reply and track whether I get one. I'm imagining some combination of Bayesian classifier and text analytics that looks for questions or key phrases to figure this out. I don't know if this is what might be suggested by the "Waiting On" section in IBM Verse... if so, very cool.
2. Auto Delete / Archive: Intelligence to automatically delete or archive emails that have expired. For example, if I have an email about a server outage that happened last week, can't that be deleted automatically? Or if there was a 20% off sale that ends on December 1st, can't that be deleted once the sale has expired?
3. Email Expiration: Slowly expire certain emails (e.g., newsletters, marketing emails, etc.), and present the expiring emails to me in an intuitive way so I know whether I'm about to lose an email for good.

Hopefully IBM will offer up more details on Verse and I'll get access so I can check it out for myself. I do hope that there is more than what they're currently sharing on the site and their videos. And hopefully we'll be seeing some truly great innovation in email, as I do agree with IBM that there's got to be a better way.

A Product Manager's Wishlist for ZipCar

As someone without a car who needs to regularly visit my client's office 60 miles from Boston, I'm a pretty frequent user of ZipCar. This means two things: I've seen the ups and downs of the car share service, and I've got a lot of time to ponder whatever pops in my head. If I'm hungry, that usually takes the form of recipes I invent that I never actually cook (probably for the best). But the other day, my mind turned to ZipCar.

It could be just a result of driving ZipCars more often, but I've noticed more issues in the last year than when I first started driving them. This ranges from minor annoyances--like cars that are missing their aux cable--to things that are more serious--like dangerously under-inflated tires and cars out of coolant.

I don't think I'm going to switch to a competitive car service anytime soon, but I did have some ideas on what would move the needle back up on the customer experience front. So ZipCar, here it is...

Automatic Fuel Reporting

Even this picture is enough to make me cringe.
creative commons licensed (BY-NC-ND) flickr photo by dmoola: http://flickr.com/photos/dmoola/730766000

I've never understood why I as a driver have to report a low gas tank. Although I know almost nothing about cars, I don't see why this can't be automatically figured out using the car's OBD port. They already have telemetry that reports mileage, and integration that lets you honk the horn from a mobile app, so it doesn't seem like a big leap for them to do this.

Assuming this is doable, if a member returns a car with under 1/4 tank, they would automatically get fined with part of that fine going to the next customer. This is a change from the current model, where ZipCar fines a customer if the next customer reports a low tank, but keeps the money. Although I assume this is done to prevent people from falsely reporting low gas to score some cash, it does nothing for the customer who could now be late because of the need to get gas.

Since I'm on it...

App-based Fuel Reporting

Let's assume there's a technical reason preventing automatic fuel reporting. In this case, I don't understand why I need to place a call and navigate a call menu to report low gas. If I'm in this situation, I'm already annoyed by low gas, so it should be as easy as possible for me to report it. Why not put a low-fuel reporting feature directly into the app, and have members snap a picture of the gas gauge to reduce false claims? This could be done in three taps in an app instead of time spent on a call.

Speaking of the app...

App-based Damage Reporting

I'll admit that I'm not the best at always doing the walk around to check for damage. But if I do the walk around and see something I need to report, I again need to call in, navigate a call menu, and then leave a voicemail to report the damage. Wouldn't it be easier if there was a Vine-like easy video capability in the app? I could just walk around the car while recording the video, and if I see anything, tap one more time to have the video sent to ZipCar HQ, and be on my way with a minimum of time lost.

App-based Reservation Notifications

This would rock.

Next, I'll suggest they take a play from the Uber playbook... the one that's not getting a ton of misdirected negative attention. Earlier this year, Uber switched from SMS to app notifications to notify passengers of the status of their. I love this change. My driver details are right in my notifications drawer, so it's easy for me to check the model and license plate of the car that's picking me up.

ZipCar is still relying on SMS, which reminds you of the car name, location, and reservation time either 36 hours or one hour ahead of your reservation. The 36 hour notification is fine as is--it has reminded me to cancel cars I didn't need anymore without getting charged--but I think the one hour reminder could use some work. Given that the names of ZipCars aren't always visible, and given also that I have a near complete inability to distinguish between cars using anything other than color, why not pop up a notification with the reservation details PLUS the car color and license plate? This should also reduce the scenarios where people take the wrong car by accident, which I'm sure causes headaches for both members and ZipCar staff.

ZipCar Loyalty Program

I'm using PowerPoint as my image
 editing tool of choice, so be nice.  

Now, for those members who use ZipCar a lot, how about turning the rumored loyalty program into a reality? This would be a good way to reward heavy users and even out all the issues they run into. I'm all about tying it into some type of good karma program to reward drivers who keep the gas tank filled and perhaps even get the car washed every now and then. It wouldn't take much... maybe just a free two-hour rental here and there to make errand running a little sweeter...

Something for the Techs

5.8 pounds of 100 PSI love. Rowr.

Since it's not all about me, here's something for the techs... so they can keep the tires full... so I'm not riding around on dramatically under-inflated tires. Fine, it is all about me.

That sexy beast you see to the left is just $44 for a 4.5 star pump. Add it to the tech kit, and we all win--properly inflated tires, a safer ride, and better gas mileage.

So ZipCar, there is my wishlist. PS. Christmas is coming, and I've been a very good boy.

#DataEast14!

After not doing much on the data science front for quite a while, I'm excited to be attending the DataEast14 Big Data Innovation conference here in Boston. Two days of what looks to be a series of great talks and interactive sessions.

As enthusiastic as I was about the session, I was less enthusiastic about the format of the schedule itself... it was a little tricky to read through the sessions to try to chart my day. So I dusted off my XSLT found a lightweight XML editor in XML Copy Editor and built a clickable grid. This way, I could keep track off all the sessions I wanted to attend, as there really are a lot of great topics and speakers lined up.

Day 1 of DataEast14

So hopefully this conference helps jump-start me spending more time to work on some data projects. More to come.

Dennis Crowley & The Art of the Apology

Dennis Crowley, the CEO of Foursquare, recently came under fire after it was discovered that his wife Chelsa used a fake bib to run the Boston marathon.

Although he’s since offered a more, erm… apologetic apology to the community that was upset by the actions of his wife, his original apology fell short of what a good apology should be. As I read it, I couldn’t help but notice how much of the apology was about him and his wife, and not about the people they might have hurt.

I did a quick analysis of his original response on the WCVB website, and found that nearly two-thirds of what he wrote centered on him and his wife. Only a little more than 30% of the 27 lines he wrote were some form of an apology.

In three of his four paragraphs, what started as an apology quickly switched into an attempt to justify his and his wife’s actions.

The reality is that when you're offering an apology, the party to which you are apologizing is not terribly interested in how you're feeling; they want to hear an acknowledgment of how you made them feel through your action or inaction.

As a post on the Harvard Business Review blog lays out:

In a nutshell, the problem is that most people tend to make their apologies about themselves—about their intentions, thoughts, and feelings.

“I didn’t mean to…”

“I was trying to…”

“I didn’t realize…”

“I had a good reason…”

When you screw up, the victim of your screw up does not want to hear about you. Therefore, stop talking about you and put the focus of your apology where it belongs: on him or her. Specifically, concentrate on how the victim has been affected by your mistake, on how the person is feeling, and on what he or she needs from you in order to move forward.

After some exchanges on Twitter, it seems that Dennis Crowley learned his mistake and he offered a better apology on Medium. It's probably a good reminder for all of us on how we should be apologizing the next time we hurt someone.

This is Jeopardy.

This past week, one of my colleagues flew out to do a taping for Jeopardy. He's a smart guy so I think he'll do well, and I'm looking forward to watching him when his show airs in a few months.

In the lead-up to his time on the show, we refrained from testing him with trivia, but we did get into some serious debates about wagering strategy. One of the more particular (and specific) scenarios we spent some time on had to do with the right wager to make when the last clue of Double Jeopardy is a Daily Double.

The root of the discussion is what I'm calling the Stegner Conjecture, named for the colleague who was adamant about making a big wager to put the game away, as long as you saw the category being neutral or better. His perspective is that you know more about the Daily Double category than you do the Final Jeopardy question, so you should use that to your advantage to put that game away.

While I understood his logic, I wasn't sure I would necessarily bet by his rules if I was ever placed in that spot. But... that opinion may have changed as I worked through the problem.

So first, let’s establish the scenario. For the sake of simplicity, we focused on the scenario where there will be just two players in the Final Jeopardy round. In this scenario, the two players who will compete in Final Jeopardy are separated by a small amount of money, and the player in the lead gets a Daily Double for the final clue of Double Jeopardy. Assume that this player (P1) has $10,200 and the second player (P2) has $10,000. Now, there are three basic betting scenarios:

1. Bet big to put the game away (The Stegner Conjecture) – we’ll fix this amount at $10,000; winning would guarantee that Player 1 will win the match, as they will have more than double the score of P2
2. Bet very small – we’ll fix this amount at $0; this means the game is determined by the contestants’ bets and responses in Final Jeopardy
3. Wager an amount in the middle – we’ll fix this amount at $5,000; P1 will have $15,2000 or $5,200 for Final Jeopardy

Now, we need to look at the outcome of Final Jeopardy in each of the above betting scenarios. We can break down the outcome of Final Jeopardy by looking at the probabilities for the different response scenarios, which show the final responses by score position for Final Jeopardy between two contestants. Looking at the past 10 years, in games ending with two players in Final Jeopardy:

• Right Right: 34%
• Right Wrong: 27%
• Wrong Wrong: 25%
• Wrong Right: 14%

What this tells us--assuming we are comfortable using historical probabilities to predict future outcomes--is that P1 will have a 61% chance (34% + 27%) of being right in Final Jeopardy, and P2 will have a 48% chance (34% + 14%) of being correct. P1 will be wrong when P2 is right just 14% of the time.

For what it's worth, this degree of variation from an even distribution (25% - 25% - 25% - 25%) does pass a chi-square test for significance (p < 0.05). That said, I also modeled the outcomes using a uniform distribution for comparison purposes.

Now, for each betting scenario, I determined the Final Jeopardy betting strategy that would give each contestant the best chance of winning. In some situations, the player with the lower score's bet would be irrelevant, as there would be no way for the leading player betting rationally to lose.

Based on this analysis, P1 has the following chance of winning for each betting scenario. Note that the first number assumes an even distribution, the second number uses the historical distribution.

Stegner Conjecture

• Right answer on Daily Double: 100% / 100%
• Wrong answer on Daily Double: 0% / 0%

Medium Wager

• Right answer on Daily Double: 75% / 86%
• Wrong answer on Daily Double: 25% / 14%

Low/no Wager: 50% / 61%

So now, the only task left to do is to assign a probability for P1 answering the Daily Double correctly, and then calculate the final expected outcome for P1 given the different betting scenarios and the Daily Double probability.

Expected Value of game, based on historic Final Jeopardy outcomes

Expected Value of game, based on uniform distribution of Final Jeopardy outcomes

Given this, the model suggests that:

• If you go by historic figures, you should bet big if you think you have greater than a 61% chance of getting the Daily Double correct, otherwise you should bet zero
• If you go by an even distribution, you should bet big if you have at least a 50/50 chance, otherwise you should bet zero
• There is no scenario where a medium wager is optimal

Given that you know nothing about the Final Jeopardy category, it really becomes an exercise in determining whether you feel more confident in answering the Daily Double correctly or answering a Final Jeopardy question you know nothing about correctly.

So in the end, the Stegner Conjecture holds, although I'll admit that I would find it difficult to make that big of a bet unless I felt significantly more confident than the 50% or 61% suggested above. Part of that is the emotional player winning out over the rational player, but also an indication of the difficulty in ascertaining a quantitative degree of confidence in a situation like above.

Estimation Using Probability

Earlier this year, I read Forecasting by Combining Expert Opinion, which presented a method for using probability to generate a forecast based on inputs from multiple expert parties. To do this, the author created a triangular distribution for each expert based on that person's minimum, maximum, and most-likely estimates. They then ran a Monte Carlo simulation to arrive at the final forecast in the form of a probability distribution.

Source: http://blog.revolutionanalytics.com/2014/01/forecasting-by-combining-expert-opinion.html

I thought this was a pretty smart and elegant way to arrive at a forecast, and started thinking of other areas where I've seen forecasts--project effort estimates, revenue forecasts, etc.--use much simpler means of prediction. Sometimes these are accurate, sometimes not at all.

In the world of agile software development, teams estimating the effort required to deliver product scope often use multi-point estimates as an input to their project-level estimate. For each story in their backlog, the team will provide an Aggressive But Possible (ABP) estimate, representing the effort estimate they expect to hit 50% of the time, and a Highly Probably (HP) estimate, representing an estimate they will hit 90% of the time.

Teams will then use any of a variety of methods to arrive at the product estimate; typically they will sum the ABP and then add buffer in the form of half the difference between ABP and HP, or the root sum of squares of the difference between the story-level ABP and HP.

A number of different resources point to the probability density function of agile estimates showing a right skewed normal distribution, like the one below from the Kanban Way. The ABP is the mode of the distribution, with the HP following further to the right on the curve.

Source: http://www.kanbanway.com/on-estimating-project-tasks

So now, I'm wondering about a couple things:

1. How would a Monte Carlo simulation of project effort based on a distribution like the one above compare to the project estimates based on simpler estimation techniques?
2. How would the estimate from a technique like the one I referenced at the beginning of the post compare to that coming out of a Wideband Delphi-based estimate?

I will note that I am a big proponent of Wideband Delphi, as I have used it with great success on a number of projects. The transfer of knowledge that comes during the estimation discussions can be extremely valuable. But that doesn't mean it wouldn't be fun to compare outputs of the two processes.

XKCD, Automation, and Timeboxing

I'm a huge fan of the web comic xkcd. The author's sense of humor meshes perfectly with my own, and I love the geeky/nerdy subject matter, although I'll admit there are times that I need to turn to ExplainXKCD for help. A comic of his that has stuck with me for a while now concerns automation:

Can you think of anything you do 50 times a day?

As I looked at this, I realized that I had spent more time automating different tasks (build scripts, log file checks, etc.) than I might have saved.

But at the same time, even if I didn't save time from the automation, what made it worthwhile was:<

1. The elimination of mundane tasks 
2. A reduction in errors caused by the manual execution of said mundane tasks

I was letting this idea germinate a bit, hopefully into a potential blog post, until I saw this comic about a week ago:

Check and mate.

Yep.

You'd think I would have added the satistfaction that one gets from completing a project to that list of what makes automation worthwhile. But as xkcd calls out, the reality is that many times these projects never complete as there is an endless loop of thinking and tweaking as you continuously improve it.

I'm even facing this now, in terms of an "alpha" release of a new version of an Excel-based scoping tool we use at work. I reached out to a few folks to be early testers to get feedback on the core changes, but that was weeks ago and the spreadsheet is still being used just by me as I endlessly tinker with it.

Time to embrace my inner-agile practitioner and enforce some discipline around timeboxing, I think.

My new home

I've had a couple homes on the web for a while now... there's my About Me, the old BasilHayek.com (below), my start at a data science blog, and the requisite social media sites (LinkedIn, Twitter, Pinterest).

How did this not win a Webby?

This is an attempt to bring my scattered web presence together into something I can update a bit more often and traverse a broader range of topics on.

Giddyup.