�ݺ�ߣ

Editor's Notes

1. Not that I’m here to promote TripCase, but it seems like this story will make a little more sense if you know what the product is I’m talking about. TripCase is a neutral itinerary management solution. What that means is we take all your trip information, regardless of where you booked, and put it together in one place for you. We then offer tools and services like weather, flight notifications, hotel information on top of that. Its completely free and available for iPhone and Android today. People love it.
2. Roadmaps are moving targets. There are always more things on them than can ever get done, and you’re always under pressure to get to the next thing. With my team, we manage this by focusing on 3 principles
3. With my team we manage this by focusing on 3 principles: Ship Frequently Measure and Iterate Deliver Value Incrementally That sounds pretty basic. But how do you make this work in practice?
4. We’ve all seen the art where multiple paintings combine to make a larger work of art. Each individual painting can stand on its own, but together they make a much more fulfilling work of art. This is how we view our features in TripCase
5. From it’s inception, TripCase was all about the traveler. But we discovered that people were using TripCase to share their trips with friends and family. So about a year ago, we started building a feature called Follower View. The goal was to let someone follow a trip and see the same thing in their TripCase account that the traveler saw. Pretty simple. Until we started breaking it down.
6. We knew we’d need to add a following tab. And you’d probably want to see the traveler name. And if you’re going to make it a big feature, you probably want to make it really easy to share your trip with a follower, so we’ll need to revamp that. Should I be able to pull from my phone contacts? What about the desktop version? Should I let a follower be able to follow trips themselves? Search? Send things back to the traveler? It’s the snowball effect: what started as a small feature grows until you’re wanting to redesign entire app.
7. You’ve probably heard the term frequently “Minimum Viable Product” or MVP. It’s the concept of building the bare minimum product you can get out the door, and then iterating on that. It is good in concept, but resulted in a lot of companies shipping really terrible first drafts that really should have been prototypes, not products.
8. In fact, this concept has been so misused and overused that it has really become almost a curse word in the tech industry. Especially when you’re an established product with an established user base, your customers expect more from you than a terrible first draft of a feature.
9. So when we’re building TripCase, I like to think of things from a little different perspective. Rather than MVP, I look at the MVRP, or the Minimum Valuable Release Point. This is really the point in a project that we’ve broken down where there is enough value to make shipping possible. Could we deliver before? Probably. Would it be something our customers want? Not really.
10. So when we’re building TripCase, I like to think of things from a little different perspective. Rather than MVP, I look at the MVRP, or the Minimum Valuable Release Point. This is really the point in a project that we’ve broken down where there is enough value to make shipping possible. Could we deliver before? Probably. Would it be something our customers want? Not really.
11. First built out Contact List and used that to enhance our sharing workflow.
12. Once you could share, we added following to mobile.
13. Then added following to desktop for administrative assistants, and even broke that into two releases, following on with the search box.
14. By breaking down features you can
15. Once we break down features, find the releases, and really scrutinize scope, there are always a number of features that still end up below the line. What happens to those items? I’d like to say we just keep going until they’re all done. Unfortunately a lot of times, we reach a point where we need to move on to the next project and some of the items on our wish list are still not complete.
16. So at TripCase, our leftover items end up on a backlog to be worked in the future. This backlog is not small. So how do we decide what to go back and do?
17. So at TripCase, our leftover items end up on a backlog to be worked in the future. This backlog is not small. So how do we decide what to go back and do?
18. Data. At TripCase, we have made a commitment to making data-driven decisions. Whether that is usability testing, support data, or analytics on usage, we are constantly looking for information to help us better prioritize what we build.
19. Last year, we were a launch partner with Uber for their Developer API. We integrated their APIs into TripCase to allow travelers to easily see the estimated cost of an Uber ride to their next trip item, and at the user’s request pass addresses directly to Uber so the driver would know where they are going. Being up against a launch deadline, we had to meticulously scrutinize scope and make sure we were focusing only on the most important features for launch.
20. One item that fell below the line was allowing the user to change their pick-up and drop-off locations and re-generate price quotes. Good features, but up against the wire we decided to cut them. We had quite a bit of internal debate: was this even valuable? You can’t pre-book an Uber, so why would anyone change the pick-up location? You clicked on the button from a specific trip item…why would you change the destination? Since we couldn’t ship with the feature anyway, we decided to test.
21. One thing we know about mobile users: if they think that something should have a click-through, they will tap whether or not there is any visual cue. So we put analytics on the pick-up and drop off locations to log any time a user TRIED to click them
22. The results were pretty clear: users wanted to change the pick-up location. They don’t care as much about the drop off. We are always looking for ways to do this in TripCase: develop a hypothesis about what users are interested in, and then find a way to test their intent where it makes sense.
23. So we added the ability to change your pick up location, usage of the tool shot through the roof and everyone was happy….right? Wrong. Unfortunately you can have all the right data and see the clear answer, but sometimes your priorities can make it difficult to go back and finish it out. Which bring me to my last point:
24. We didn’t do it right with Uber, but I do want to tell you a couple of examples where we did.
25. We redesigned TripCase in 2012 with a big vision: making the action of travel as seamless as possible, walking a traveler through a trip and presenting the most important information right at the time it was needed.
26. Breaking down the feature, we first focused on getting the cards right – presenting relevant information for each item. But we left all of the messages grouped together and just let the traveler swipe through their trip items. Travelers liked it, but our usability testing showed travelers still preferred the full step by step vision
27. This summer, TripCase released our newly redesigned action view separated messages to be attached to the item that makes the most sense, and introduced a destination card to provide tips and advice on things to do in your trip.
28. The result: the rate of clicks on these messages increased.
29. Another example of this is our new Apple Watch app. TripCase was one of the first apps on the Apple Watch, being ready at launch. However, at launch we did not have a glance view. For those of you who haven’t seen an Apple Watch yet, a Glance view is a persistent menu that you access by swiping up, and gives you a carousel of the most important information from your apps. It is intended to be a quick “glance” of you the most useful data on your watch. After introducing the app, contemplated going back and building a glance view. Looking at customer reviews and requests, competitive benchmarks, and our own usage of the watch, we realized it was really a valuable use case for travel on a watch.
30. We introduced the Glance View in June, and within 1 month saw a 20% increase in our overall watch activity (normalized with new users)
31. So when we’re building TripCase, I like to think of things from a little different perspective. Rather than MVP, I look at the MVRP, or the Minimum Valuable Release Point. This is really the point in a project that we’ve broken down where there is enough value to make shipping possible. Could we deliver before? Probably. Would it be something our customers want? Not really.