Xnote

Xnote was a tool that let you annotate articles from the web and share them. I worked on this project for the first 7 months of 2015. I found a doc full of notes from those days. Here’s a summary.

Motivation

I was frustrated with how much dead work [1] was involved in sharing and discussing articles with friends, through my phone. I would copy and paste article links in FB Messenger to share with individuals. Then I’d talk about the parts that were interesting by copying and pasting those snippets, and then type out my thoughts about those parts.

Then, if I wanted to share that train of thought with someone else, I’d have to do some more copy pasting each quote and point. I wanted a way to embed my thoughts directly onto an article and be able to share that index whenever I wanted to share the article.

Imagine the commenting feature in Google Docs, but for any article on the web. Actually, you don’t have to imagine, here‘s how it worked:

1. Save an article to Xnote, 2. Open, highlight to trigger annotation, 3. annotate, 4. (not shown) Share with others.

Learning:

Prepare for a Longer Timeline

I started working on Xnote in February of 2015. I gave myself till the end of summer (Till mid-August) to work on it — and only continue if Xnote “took off”. Viggy joined me in March to help build out Xnote.

We took two and a half months to develop the first Android version, leaving us only a couple of months to get feedback and iterate. I didn’t leave enough time for growth.

This is what growth for many companies looks like:

Credit: Ooshma Garg@Gobble during her talk at YC

Gobble didn’t start growing until a year after launch. And took 3 years to reach the “promised land” — when the curve finally started to take off. This isn’t uncommon.

Achieving any level of growth can take a while. I ignored this.. I wanted to see rapid growth, and felt that if I didn’t see it in the span of a month, then the product wasn’t really useful. We stopped work way too early.

Set Clear Goals and Milestones

I didn’t have a clear goal in place that would help me decide whether I would continue working on Xnote after summer. In hindsight this was a cop-out strategy. If I had set a goal to grow the user base to 1000 active users (who use the app for at least an hour a day w/ at least 5 days of usage in a week), then if I didn’t hit it, I’d know that I had failed and by how much.

By not setting a concrete outcome goal, I avoided a failure scenario. Building and growing a product involves navigating through ambiguity. Creating structure in that chaos is important. Having a clear win/lose situation is necessary for accountability and direction.

By avoiding a win/failure outcome, I didn’t have to admit that I failed. In reality, I failed by default for not setting up a goal.

Seek External Feedback

Friends are nice. They want to see you succeed. I still crack up whenever I take look at our initial reviews.

Seek reviews from people you don’t know. Be persistent. Good reviews take time and effort.

Create Ownership

Viggy and I aimed to divide work in a way that minimized inter-dependency — meaning we wanted to minimize situations in which one of us is waiting for the other to finish work in order to proceed. Ideally we would pick up independent features or independent parts of the code base (for example: he would do front-end, and I would focus on all of the back-end). We couldn’t divide up work this way at the start because Viggy needed a bit of time to understand how to build stuff (and I only barely knew enough to be dangerous)[2].

Instead, I laid down the architecture for both the front-end and the back-end for the major features, and Viggy worked with these models. This meant that Viggy didn’t really “own” any particular feature.

I believe ownership is important when developing products in teams. People work best when they know what they are responsible for, and have something to show to their peers as their work in the context of the organization’s.

A good way to check for optimal division of labor is to ask the question “What do you work on?”.

“I’m working on the payment portal for all purse purchases” is great to hear because it shows that this person has a clear understanding of their responsibilities and ownership. If something goes wrong with the payment portal for purses, everyone knows who to go to. At the same time, if there’s something cool about this portal, people know who to congratulate.

“I’m working on a little bit of the front-end for the payment portal, some documentation for the database layer, and oh also some data cleansing to hand over to the data science team”. In this case accountability is spread across team members. Not good.

Of course the latter is often inevitable, especially early on in a team’s growth, but I think it’s smart to push the organization in a direction that minimizes this complexity.

After a couple of months of development, Viggy owned much of the front-end feature development. I loved what he produced, and noticed that he was more enthusiastic about his work as a result of owning an entire piece of the product.

Strategize Growth From Day 1

I really, really wish I had read Traction, and Patrick Mckenzie’s posts before I had worked on this. I had a working product and I just sat on it. I had no strategy beyond sharing it on Facebook, presenting the app before / after CS lectures on campus, and stopping strangers in the corridor asking them to give me feedback on it.

If you’re working on a product and haven’t yet thought about how you plan to drive its growth, I highly recommend taking time to think through a growth plan. You might end up changing it a lot once you actually start experimenting, but it’s useful to think through because it forces you to get in the habit of budgeting growth in terms of time, effort and $$.

Reflect Periodically

Post-mortem analyses are painful. And incredibly useful. It’s even more useful to sit down every week or so and think hard about mistakes from the previous week. If I had done a better job at that, I wouldn’t have fallen into the many pitfalls that others have fallen into and wrote about (shoutout to csallen@IndieHackers for creating a forum for software business topics).

There’s a lot of content on the internet to learn from others that have walked similar paths. Leverage that experience.

References

[1] “Dead work: Work which must be done to prepare for future operations but from which there is no direct return (as stripping the surface to expose rock which is to be quarried)”

[2] This was Viggy’s first actual software project outside of class assignments. From my experience with class assignments, they teach very little about actually building and shipping product.