This is yet another post where the tl;dr is “SHIP IT!” but with a Pivotal perspective. It can be easy to hold back an initial launch, especially when you’re trying to attract customers, not offend them. I submit that with the right tools, you can not only minimize the impact of releasing early, but create customer delight from the pain whereas perfection out of the gates would have produced none.
If your software can enable users to do the core thing you want, no matter how tangled the experience is, you should ship today under one condition: You must be able to ship again tomorrow, and the next day, and then two hours after that, and then the following Friday. In his post, 1.0 is the Loneliest Number, Matt Mullenweg talks about how that first hurdle is a big psychological barrier. He speculates that Apple employees were embarrassed at the known shortcomings of the first iPod, anxious to get a better version out before the first one even shipped. A conversation I had with my own PM was reminiscent of this. He, along with myself and the rest of the team, has a lot of pride in his work, and this project in particular. Understandably, he wants the first user to have the best experience possible. And while I agree that I want the user to be happy, I know that his experience could always be improved.
You could rephrase this idea to the proverb, “Perfect is the enemy of good.”, meaning that you shouldn’t let perfection get in the way of doing good things. Another quote, said by one of our team members struck true form most of us: “If you waited until it was perfect, you waited too long.” But I think the thought that really bring it home for me is this, “Would you rather they have an imperfect experience now, or that they have no experience at all?” I like this because if the user has an experience, the user learns something about you, and if you’re lucky (or directed through user testing), the user gives you feedback and you learn something too.
When you learn something, you can take action on it. Before that learning happens, you’re just guessing, shooting wildly in the air hoping to hit something. Delivering perfection on the first try must be near impossible with this method. Thus, like all things Pivotal, we do what we can to shorten the feedback loop – getting feedback, making a decision to act, and delivering must take as little time as possible. To do that in software, that means a few things.
First, priorities must be flexible. If something important comes along, you shouldn’t have to wait six months to get it in the next release, and you shouldn’t have to worry about the implications of scuttling the sprint. We do this using our own tool, Pivotal Tracker which lets you easily drag the most important story to the top of the work queue.
Second, you must be able to respond quickly. If Joe is the only one who knows that code and he’s got six other high priority things to do today, you’re out of luck. That’s why we pair program and rotate, so that anyone on the team can pick up the next story that needs attention and everyone is familiar with all parts of the codebase that the team is responsible for.
Lastly, you need to be able to ship fast. There’re can’t be a two day release process on a thirty minute code change that only happens on Tuesday’s and Thursdays. It has to ship as close to now as possible, otherwise you’re wasting value by letting it sit on your virtual shelf. At Pivotal, we are always ready to ship because we don’t know any other way, our stories need reviewing, and that usually means shipping to some sort of prod-like environment, so we have to ship multiple times a day to keep the story feedback cycle small. If this process were anything other than dead simple, we’d need a pair on deployment full time just to keep up. Often times we configure our CI server to automatically deploy upon successful test runs, or in the worst case make it a manual one-click to deploy. The same technique is readily applied to production too. From there it’s up to the team to minimize downtime during deployments using whatever strategy is appropriate for the application.
But how does all this create customer delight from strife you ask? Picture the last time you withdrew cash from an ATM. You put your card in, punched some numbers, and hopefully the right amount of cash spits out. How would you rate that experience from these three choices? A) Meets Expectations, B) Excedes Expectations, C) Below Expectations. I’m guessing you didn’t get wowed by the ATM unless this was your first time taking cash out. It probably wasn’t below expectations since you got what you wanted. Rather, it was just a ho-hum experience.
What if instead, you put your card in, punch some numbers, and it buzzes for a while and shows you your receipt, but never gives you the expected cash money? Now you’re pissed. You wanted to use this service and it let you down. You really want cash, so you call the bank, planning to give them some strongly worded feedback. However you find yourself completely disarmed because the person on the other end of the line is really listening to you, not reading a script, and they quickly identify the problem, add back the money to your account, and tell you that they’re sending out a technician to fix the machine so that you and future customers have a much better experience in the future. WOW! I bet you’re thinking, “I would love to have a bank like that!” By shipping software that works in many cases, but has a compelling story to turn failures in to successes, you create a loyalty that’s a much better engine for your company than “Yeah, it meets my expectations.” Let them see you fix things. Let the users feel empowered to tell you what needs the most attention.
In the end, if you feel like you could ship, you should ship and feel good about it. You’re putting a valuable product in the hands of the users you want to help sooner. And if you’re doing it the Pivotal way, you can address their pain points quickly to change customer dissatisfaction into customer delight while being directed about how you spend your time and resources.
