Lessons learned adding messaging to a notes app (Guest Post)

[Today we have a guest post from Alex Schiff, who’s a co-founder and CEO of Fetchnotes, which makes simple, smart tools that help people work together and get things done. Fetchnotes graduated from Techstars Boston in November 2012, and is currently a team of 5 in Cambridge, Massachusetts. -Andrew]

Alex Schiff, CEO of Fetchnotes:

There’s a big craze in messaging right now, and everyone seems to be trying to integrate some form of it into their product. Having learned that people who shared notes were way more likely to build a habit with Fetchnotes, we definitely caught the bug in our last iteration. It also coincided with a goal to evolve our value proposition beyond just personal organization — there’s just a lot of noise in that space.

A more detailed overview of that product, featured to the left, can be found here. To summarize, we wanted to create an organized feed for the things you’re keeping track of as well as the things other people want you to be keeping track of. Effectively, we built out messaging features (revolving around @-mentions) that allowed you to communicate in a hyper-organized way, on top of what was still at its core a personal notes/to do list app.

We learned a lot about the way people communicate and work together (which is informing a lot of future product plans), but we didn’t really budge the core metric we were trying to move: % of monthly active users sharing at least one note per month (below).

The % of users sharing actually went down before returning to pre-launch levels. We had a large influx of users from launch press, but the sharing value proposition still didn’t click. As a result, we had an even higher percentage using it as a personal notes app. Not the results we wanted, but we learned a lot in the process.

For anyone out there building social products, I wanted to share some of those lessons.

Be aware of invisible mental walls

Before we launched this iteration, a common complaint we heard was that the places people kept track of information personally tended to be isolated from where other people sent it to them (email, SMS, and other communication channels). This was pretty consistent across both people who used Fetchnotes and people who used other tools, and it was a major influence on the product we designed.

It turns out that while information silos are indeed a pain point, a major reason they exist is because people tend to think of “personal stuff” and “shared stuff” differently. They don’t want them co-mingled in one organizational area. When we started asking people the right questions, we also found “I need to send this to someone” is just not the same mental mode as “I need to remember this for myself.”

With good reason, too — here are some problems that you run into when you try to combine the two:

  • People have different ways of organizing, prioritizing, categorizing, etc. that conflict with each other. And they are very particular about it — everybody’s a little OCD.
  • Where you keep track of personal information is sacred. When other people’s stuff start showing up, you feel like it’s not yours anymore. That leads you to not want to put deeply private material there.
  • Messaging/communication is inherently noisy and chaotic. Personal organization is about order.

Most often, people bucket Fetchnotes as either social-only or private-only, and generally it’s the latter. So if you’re building a product that has anything to do with shared and personal organization, make sure you give people walls to protect their “personal space.”

The concentration of communication channels

We were trying to get people to use Fetchnotes to communicate things that had an element of permanence or action. It was all about adding things to people’s lists — i.e., organizing your communication so it was where the recipient wanted it (featured to the left). What we didn’t want was the more conversational fluff, like this:

At that point, we might as well be having a conversation in Google Docs.

By talking to a lot of users and non-users about their habits, we learned that communication channels tend to concentrate around only a handful of categories:

  1. People. “When I want to talk to Hans in Germany, I use WhatsApp. When I talk to my mom, I use SMS.”
  2. Context. “When I want to talk about work stuff, I use Slack. When I want to talk to my friends about going out later, I use Facebook Messenger.”
  3. Media type. “When I want to send my friends photos, I use Snapchat. When I want to communicate via text, I use SMS.”
  4. Publicity. “When I want everyone to see my thoughts, I use Twitter. When I want to send messages privately, I use SMS.”

If someone can’t use a product for all of their communication within one of those buckets, you tend not to use it for any of your communication. There are certainly exceptions, but they’re exactly that — exceptions. People need an extremely clear mental model to answer the question, “When do I use this app?”

Regardless of what product you’re building (though it’s especially true in messaging), make sure that your users can answer that without having to think.

Make sure your “viral hook” is organic and frequent

Our users frequently asked for ways to share their notes with non-users, and that underpinned a big part of our growth strategy. That was the thinking behind our address book integration, which actually works quite well when people need it. In fact, about 25% of all notes shared are shared with non-users (via SMS or email).

The problem, as we realized, is that communication is about sending (one-way) information to another person. When I message someone about say, a link I think they should check out, I’ve already checked that link out. I don’t need to save that information for myself, so I have no reason to send that information to you via Fetchnotes (since it will just send you a text anyway). People do share with non-users in other ways (like sharing pre-existing notes after the fact), but that behavior isn’t frequent enough to make an impact on growth (less than 1%).

So as you’re thinking through your “viral hook,” make sure you’re building it around something that people organically need to do, and need to do often. “Non-user sharing” around inorganic behavior is just an invite system no one uses. Get granular, map it out from beginning to end, and talk to people about how they accomplish these steps currently. Don’t take shortcuts or make assumptions.

Your network-specific identity is probably confusing people

Way too many companies start off thinking, “We need our own identity!” Pretty much every major social network has one, and they’re enticing from a brand perspective (i.e., “Follow me @alexschiff on Twitter!”). However, most products don’t really need usernames to be front and center. People don’t want yet another identity to think about, and it usually ends up causing a lot of design complexity. Product managers tend to believe people will value their usernames, but unless you’re a product that is public in nature people stop caring after five minutes.

Again, say it with me: No one gives a shit about your username.

Ideally, identity should be something that fades into the background of a social product. Particularly for productivity-oriented tools, no one wants to share with “@alexschiff” — they want to share with “Alex Schiff”. Unless your product is public in nature, you might not even need a username at all. Either way, focus on real names, not aliases.

How groups adopt tools

Finally, we noticed a major trend in the way groups adopt tools — one that existed across families, businesses, friends, and pretty much anyone we talked to. We identified 3 major personas when a group chooses to use a new product, and one of them is much more important than the others.

The Leader

The leader isn’t necessarily the “alpha” of the group, but they’re the one who takes the lead in planning and organizing. More importantly, they’re the one who searches, evaluates and introduces a tool into the group — they want to use something to improve efficiency. They would generally set up Fetchnotes, load in a bunch of information (i.e., a list of prospective apartments you’re sharing with your roommates), and start using it completely. Frankly, they’re not that picky — they just want it outside of the noise of normal communication channels.

The Engaged Follower

The engaged follower is the person who contributes to the conversation, but defaults to using existing channels like email or text. For example, rather than adding a new apartment listing in Fetchnotes, they would send everyone an email, text, FB message, etc. They vary in reluctance to adopt new technology, but the unifying pattern is that they end up dragging the conversation back into email by not using the chosen tool.

The Passive Follower

These are the people that just go with the flow on how things are planned. They might contribute a little or not at all, but they’ll generally just go wherever the conversation is happening. This is because, for them, the conversation is more for reference than it is actively contributing their own ideas and effort.

Today, collaboration products are built for the leader. In other words, they’re built with the assumption that everyone in the group is planning on using it. But the secret truth is that they’re already plenty satisfied with the tools available — it’s the lack of adoption by other members that causes problems.

The key to getting group collaboration tools adopted, I believe, is by making it work for the “engaged followers.” The “passive followers” will go wherever the conversation goes, and the leaders are generally satisfied with the tools that already exist — besides the fact that no one will use them.

So, we’re working on exactly that — stay tuned ☺

Exit mobile version