We have set our Openly goals for the next two months (from now until the end of March when the Antler program ends). Our #1 goal: Achieving product-market fit (PMF). That basically boils down to continuing to build Openly and finding a group of users that absolutely love it.

There do not seem to be objective, numerical indicators of product-market-fit. Rather, as Marc Andreesen describes, it’s very subjective:

[Y]ou can always feel product/market fit when it’s happening. The customers are buying the product just as fast as you can make it — or usage is growing just as fast as you can add more servers. Money from customers is piling up in your company checking account. You’re hiring sales and customer support staff as fast as you can. Reporters are calling because they’ve heard about your hot new thing and they want to talk to you about it. You start getting entrepreneur of the year awards from Harvard Business School. Investment bankers are staking out your house. You could eat free for a year at Buck’s.

Or, as my co-founder Jessy said:

If you are asking yourself whether you have achieved product-market fit, then you probably have not.

Achieving product-market fit always involves serendipity. But it’s not just luck alone. The two key activities that will get us in the right direction are product development (building out our Openly application) and customer development (acquiring users, testing assumptions). This is how we will spend most of our time over the next ten weeks because there is nothing more important for a startup than achieving product-market fit. Jessy will tackle customer development and I will focus on product development.

Our two other Openly goals are:

  1. strengthening the foundation of our business (see yesterday’s post) by doing weekly iterations of Riskiest Assumption Testing (RAT)
  2. applying to a few more accelerator programs (Techstars, 500 Startups, and Alchemist).

We also spent some time talking about the product development roadmap in order to identify the next steps/features for our app. Here is our list of options:

  1. Search
  2. Manage collaborators
  3. Invite friends/colleagues
  4. Core Drive Features (add, move, rename, delete files)
  5. Pull Requests
  6. Redesign w/ vertical nav menu
  7. Issues/Discussions
  8. Speed Improvements and progress indicators for setup, revision restore, PR creation, and PR merge
  9. Code Development Speed & Sustainability: Code extraction into gems
  10. Diffing for other file types (which ones?)

The interesting thing that Jessy pointed out here is that there are essentially two types of items listed here: 1) New features (things that users currently cannot do) and 2) improvements to existing features (things that users can already do but that are slow/painful/inefficient).

New Features Improvements
Pull Requests Search (can be done in Drive)
Issues/Discussions Manage collaborators (can be done by us)
Diffing non-doc file types Invite friends/colleagues (can be done by us)
  Core Drive Features (can be done in Drive)
  Redesign w/ vertical nav menu (no new functionality)
  Speed improvements, … (no new functionality)
  Code Development (no new functionality)

We have decided to focus our energy on new features and spend as little effort as possible on improvements. That’s not because we are mean and want our users to have a terrible time, but more because having a product that’s painful to use is actually a good test of your product’s value: Are the benefits that your product enables so valuable that I as a user am willing to go through some pain to use it?

Of course, if any of users considers one of these improvements a deal-breaker, we will implement it. But we’ll hold off on initiating the development of these improvements until requested.