The funnel

When designing a solution to a problem, think about users going through a funnel. You need to keep all functions in mind so that they’re all inherently integrated into the product -- sales and marketing cannot just be an afterthought. Generally, the funnel is:

Get user in the door, on your website or app (marketing)
Get user to sign up and / or pay (sales)
Get user to use your product (product onboarding)
Get user to the ‘ah ha’ epiphany moment (when they realize why you’re product is so essential to their life / work) so they come back again (product retention)
Get user to invite more users (repeat cycle, marketing)

At each step along the way, the user has to see a clear benefit or else she/he won’t move on. Like how water naturally flows downhill, users will take the path of least resistance including abandoning your product. The incentives have to be aligned at each step for the user to keep going. When testing with users, make sure to start from the very beginning of the experience, unless you’re testing something in the middle after you’ve nailed the onboarding process. More on first time user experiences later.

Depending on what type of product you’re building, this funnel can be different. There are frameworks on the internet to think through this. Keep everything intuitive and simple - cognitive complexity is resistance that will doom your product.

The importance of user interaction design

In addition, the UX (and UI) design of your product really influence the way users think about how they should use your product. The difference between the process of creating and sharing a photo on Snapchat and Instagram are very different. They play to each app’s purpose (quick and disposable for Snapchat vs beautiful and presentable for Instagram).

With Bloon, I wanted users to organize impromptu, day-of activities. But the way I set up the UX, it looked more like a Facebook event which are for events planned way in advance. And so users used Bloon in this way. To combat this, I simplified the ‘create activity’ form by removing some less necessary inputs. As a result, the average days between the day the activity was organized and the actual day of the activity improved by over 50%, from 5.8 days to 2.6 days (lower is better).

Don’t listen to every user equally

Who are the right users? Who’s using your product ‘correctly’? These are the really difficult questions that you have to figure out. Be careful with all the false positives. Continually figure out who your users out, and again be open minded.

Don’t focus on the small changes that won’t have much of an effect on proving a hypothesis out. You don’t need a highly polished product while testing out a hypothesis. Get it to the point where it’s good enough and just test. A lot of people will want to give you feedback (e.g. minor UI changes) that which upon it’s implementation, wouldn’t the change the trajectory of the product.

Don’t get sucked into trying to optimize a local maximum. You can avoid this by telling testers beforehand that you’re not looking for feedback on the details, but more on the bigger picture of whether or not this service would be useful, etc. After you get the bigger picture feedback, you can always go back and get feedback on the details. But it’s more difficult to go the other way around because the tester can be so focused on finding small changes they’d like to be made.

It’s easy to get sucked into a time consuming cycle of making changes to try to appease everyone. And it is difficult to determine what the false positives are. You can spend a lot of time working on something that many people say they want, only to see very few people use it after implementing it.

This happened a few times with Bloon:

Calendar invitations
It made sense that you should easily add an activity to a calendar. And one of the bigger problems organizers had said they faced was that people would forget / flake. I tested it out by manually sending out calendar invites behind the scenes, and users loved it. But adding a calendar feature required separate time, date, location fields, making it more complicated to create a activity. More importantly, it shifts Bloon more into the category of Facebook events, which is a service Bloon can’t compete against. I spent a few days building this out, yet not many people ended up using it.

Scheduling
Users said that scheduling (finding a good time) was a big problem, so polling times in addition to interest would be valuable. And I saw it in users’ behavior too: users would try to find a good time via group chat after an activity hit critical mass. But there were two problems: (1) polling over SMS is a terrible experience, unless you just provide a link to a doodle (in which case why not just use doodle), and (2) figuring out a time isn’t a multiple choice question most of the time, it happens through convergence. This feature didn’t fit in well with the existing product so of course very few people used it.

In both of these cases, adding these features didn’t make Bloon more useful than existing products. In the case of calendar invites, it actually positions Bloon more like a Facebook Events, and in the case of scheduling, it positions Bloon more like Doodle, neither of which play to Bloon’s strengths. When mulling a feature, think about how it would position your product versus your competitors’, and if it would play to your product’s strengths / purpose.

Focusing on doing one thing extremely well is one of the keys to success. These features that users wanted distracted me from the bigger picture: figuring out whether or not the essence of Bloon (my original hypothesis) was working or not. These features would only help existing users anyway (and probably not significantly help with retention), not attract new users.

Conclusion

These are just a few high level things to keep in mind while doing product development, especially for a new product. If you’re interested in reading more on product management, read Marty Cagan’s Inspired: How to Create Products Customers Love. If you’re interested in learning how to talk to users, read Rob Fitzpatrick’s The Mom Test. If you’re interested in learning about how to leverage emotions in acquiring and keeping users, read Nir Eyal’s Hooked: How to Build Habit-Forming Products. I highly recommend all 3 books.