Finn Woelm

Hacker · Entrepreneur

Stories from the life of Finn, Openly, and other things.

Openly Journal

Jan 20, 2019 // 7:38am @ Tribe Theory, Singapore

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.

Jan 19, 2019 // 8:43am @ Tribe Theory, Singapore

Yesterday, we settled into Tribe Theory — the hostel focused on startups that we really liked. We have already met three fellow Antler participants here!

The past few days we did our 2018 end-of-year reflection, reflecting on things like the times we felt most alive, the strengths and weaknesses of our cofounder, and what we would do differently if we could go back to September.

It was very clear that our favorite time was late October/early November. We were launching features at the rate of 1 feature every 1-2 weeks, we had just been accepted to Antler, and we were signing up 3+ users per week. Momentum was building and it felt absolutely great! One of our goals will be to bring this momentum back, so expect to see a return to a high development pace.

During our conversation with Google in November, we realized that the foundation of our startup is somewhat shaky — we cannot confidently say what problem Openly is solving and point to data (from interviews or research) to support that statement. This makes potential collaborators like Google skeptical of what we are doing — rightfully so.

So we spent some time looking at various startup frameworks for an approach to strengthening our foundation; from Steven Blank’s The Four Steps to the Epiphany to Justin Wilcox’ FOCUS framework. Initially, we were planning to adopt one of these. But at the end of the day, we felt that we could get most of the value of these frameworks by adopting just one exercise: Riskiest Assumption Testing (RAT)

The idea is to write down all your assumptions/hypotheses and then rank them by how risky they are. For example, for us, one of our assumptions is that open collaboration will help organizations to make the world a better place. Everything we have been working on with Openly is built on that assumption. Since Jessy and I really care about the positive impact of our business, we would frankly just be wasting our time if the hypothesis turned out to be incorrect. This means it ranks very high on our riskiness scale.

After ranking the assumptions, the final step is to pick the riskiest one and test it. This can be done by doing research, talking to users, running experiments, etc. Repeat this entire process every week, DOCUMENT YOUR RESULTS (let me repeat that: DOCUMENT YOUR RESULTS*), and you will slowly be strengthening your startup’s foundation over time.

*Documentation is absolutely critical. Jessy and I did an incredible amount of stakeholder research (200+ conversations), but we did a terrible job documenting it (read: we did not document) and now we can essentially start the entire process over. Maybe you think you can remember everything, but, trust me, you will forget. Plus, your collaborators and investors will want to see your data. So document it! Trust me on this :)

Next up we will be doing some goal setting for the period of now until the end of March 2019 (when the Antler program ends). Speaking of the Antler program, it starts on Monday. Here is a screenshot of our schedule for the next two weeks. Looking intense!

Antler schedule week 1 Antler schedule week 2

Jan 15, 2019 // 8:45pm @ InnCrowd Backpackers Hostel 2, Singapore

We’ve made it to Singapore! It’s warm and humid here. I’m still trying to wrap my mind around the idea that we will be living here for the next 2+ months. Quite exciting!

We spent all day running around the city looking for housing. Looks like we’ll be based in Chinatown because that’s walking distance from the Collision8 coworking space that Antler operates out of. It means I’ll have great opportunities to practice my Chinese. But it also means I won’t be living in Little India with all its delicious Indian food :’(

From what we’ve seen so far, it looks like we’ll live in a hostel for the next two months. Jessy found this amazing hostel called Tribe Theory for entrepreneurs. As we walked by yesterday, the founder swung by. He is really well connected, the place has a great vibe, and they offered us a significantly discounted rate. What’s not to love? :)

Tomorrow, we will do our 2018-end-of-year reflection and set goals for the next couple months.

And I can’t wait to get back to work!

Jan 14, 2019 // 2:07pm @ Boeing 787, somewhere above Asia

After much back and forth, we decided to end our collaboration with our designer friend Alex. We realized that we don’t quite have sufficient data/information necessary for designing UI screens. What we need at this point is more of UI/UX research and less of UI/UX design.

It’s not that Alex is unqualified to lead the research, but rather that within the scope of our current work agreement it would not feel fair to unload this completely new requirement onto him. Plus, before any further outsourcing, we need to reevaluate our financial status. But it’s very possible that we will work together again further down the road.

We wanted to document what we learned from our first time working with a designer and first time working with a contractor:

  • Setting clear expectations upfront is crucial. We thought talking about the details of a contract at the beginning would be overly formal, but it actually helps both parties to have very clearly defined expectations and deliverables.
  • This may be unique to us, but we realized that the UI/UX ideas are much more valuable to us than the polished screens. I am guessing that’s because we’re decent at converting ideas into polished screens, but we’re not so good at coming up with these UI/UX ideas in the first place.
    To put these in other words, we eventually realized that a good 80% of the design value was in Alex’ rough sketches. If we had known this at the start, we might have changed the contract to focus exclusively on really well-thought out sketches (as opposed to polished screens), and thus gotten even more value for the same effort/money (or the same value for less effort/money).
  • We also noticed that intentionality really matters to us. The reason we were immediately convinced of Alex’ logo design was due to his great level of thoughtfulness. If you have not seen it, I recommend you check out his write-up about the thoughts that went into designing the Openly bee.
    We initially did not know that intentionality and thoughtfulness was so important to us. One mistake we made with the screens is that we did not ask for the same level of explicit intentionality. Alex probably put a good amount of thought into his screen drafts, but we failed to ask him to make that thinking explicit and thus had a difficult time understanding why one screen design should be superior to another.
  • Lastly, we realized that (at least for us), the why in UI/UX has to always precede the what. This goes along the lines of the previous point about intentionality (why) being more important than the implementation (what). But I wanted to make it a separate point to note that I believe we missed a crucial design step when we started working on screens: We jumped too quickly into what and spent too little time in the why. First, we should have done research into what use cases and user groups (power user, first time visitor, …) exist for Openly and then designing with those groups in mind.

I think it’s fair to say that one of the most valuable outcomes of this collaboration is our learning about what it’s like working with someone external to your company and how to best do UI/UX. And, of course, the bee logo! Thanks, Alex!

Dec 16, 2018 // 10:12am @ Orbis House, Denver, CO, USA

Our Singapore EntrePass application was accepted! So now it’s official: On Jan 15, we are moving to Singapore.

We finally signed a company agreement that makes Jessy CEO and CFO and makes me President and Secretary. So now we’re both officers/directors of Openly (previously, it was just me).

We also sold two million shares to each of us (out of ten million total shares). So now Jessy and I each own 50% of the company. Of course, the shares are subject to vesting over the next four years and subject to a one year cliff. And we filed form 83b with the Internal Revenue Service to pre-pay income taxes for our shares now (rather than when they vest each year and might be worth substantially more).

On the product-side, we have not made any progress. There have been too many meetings and too much papework to complete. Hopefully, we will get a chance to pick up the slack over the holidays - although those will likely be a bit busy, too.

Just two days left in the US now. The next post will be from Germany. Bye bye!

Dec 11, 2018 // 11:36pm @ Orbis House, Denver, CO, USA

We’re making very slow progress on the product side of things at the moment due to all our goodbyes and farewells with friends and mentors.

But we did join a fantastic event tonight: The Rocky Venture Club’s Sixth Annual Impact Investing event. Taking place in Downtown Denver, this event brought together entrepreneurs and venture capitalists passionate about impact. Thanks to Jessy’s Watson mentor Barb, we were able to attend the event. In addition to seeing Barb and a few other mentors and friends, we built a few new connections, too.

At the center of the event were three pitches by post-launch/pre-scale for-profit startups that were trying to make connections to raise additional money (they all already had significant investment and were looking for an additional $200-300k). I learned a lot from watching the pitches. Three things stood out to me:

  1. All three companies addressed the “exit” question: When will you exit? How will you exit (who will acquire you/IPO)? Roughly how much will you exit for?
  2. The investors asked lots of questions, particularly about all kinds of potential risk: Who are your competitors? Why is no one else doing this (having no competitors is somewhat of a risk because it means that maybe you’re crazy)? What happens to your solar panel structure when a hurricane strikes? How often do you need to calibrate your sensors? Any sorts of edge cases that they can think of.
  3. All three companies have IP. The investors, at least some, appeared to love IP.

Dec 10, 2018 // 6:53pm @ FF1 (Bus), Broadway+Euclid Avenue, CO, USA

Another post from the bus.

We spent the day in Boulder again, having final meetings with some of our closest friends and mentors over the years. If any of you are reading this: Thank you again!

Today, we had an inquiry as to whether Openly could be used to support the work of 14 or 15 students. The students are doing project-based work in teams of two to six people. They all are already familair with Git and Git concepts (such as commits and diffs). The inquirer thought that Openly might help both him and the students keep track of what everyone is doing.

Of course, we’re super excited to have Openly used in a real world scenario. We have not had anybody use Openly as a team (other than ourselves), so it’s a little bit uncharted territory. I’ve tried to think of all the edge cases where team support may be lacking — we’re good. The approximate timeline for bringing the students on: Around New Years.

We may bump up some features, such as daily notification digests, allowing project owners to manage collaborators, and organization profiles, because they were deemed useful by the person making the inquiry.

Dec 8, 2018 // 11:01am @ FF1 (Bus), Broomfield Station Gate L, CO, USA

Apologies for the radio silence. Things are a little crazy over here.

Let me sum things up:

  • Jessy got back from San Francisco on Tuesday morning
  • We booked our flights to Singapore. We’ll be arriving Tue, Jan 15
  • Jessy estimated our conversation rate for user acquisition:
    • 30% of people use Google Drive
    • Of those who use Drive, 70% of people find Openly “interesting” (i.e. like the concept)
    • Of those who find it interesting, 10% have an actual use case for Openly (i.e. Openly would solve a problem that they currently have)
    • In sum, out of ever 100 people we talk to, just about 2 will actually sign up for our beta (0.3 * 0.7 * 0.1 = 0.021)
    • That said, this is all estimation. We realized we need to do a better job tracking conversion rates. And we also need to track key characteristics of those users (such as team size, whether they work remotely, profession, etc…) so that we can form a data-based hypothesis about our early adopter group.
  • We implemented side-by-side diffs. It allows you to see a document’s content change from one revision to another side by side: Old content on the left, new content on the right. It looks very straightforward but it was incredibly complex to implement because we ran into limitations with our diffing utility dwdiff. I hope to write a blog post on that, stay tuned.
    New Feature: Side by side diffs
  • We now have 10 days left in CO. Those days are filled with A LOT of meetings with mentors and friends. We’re also meeting a lot of new people because if they live in Colorado, then this is our last chance to meet with them face-to-face.
  • In addition to all the meetings, we’re also pushing harder than ever to reach our semester goal of getting to one active user before the end of the year. Jessy is hustling to find potential users (and she’s finding them on an almost daily basis) and I’m pushing to get pull requests out the door.

240 hours left. Let’s do this.

Dec 3, 2018 // 3:56pm @ Orbis House, Denver, CO, USA

Today is my 26th birthday. Not too long ago, I could never imagine myself being older than 25. Now, I’m 26. And I cannot imagine myself ever being 30 years old.

Anyway — birthdays are always great opportunities for reflection. A lot of that belongs in my personal diary and not in this journal. But Openly is a major part of my life and so I want to take note of something that stands out to me in this regard:

I miss making people smile through the work that I do. I miss being a source of joy or happiness in people’s life. I miss making a difference with my work.

It is, I believe, a natural characteristic of this hybrid impact-profit startup that it takes a looooong time for us to get to a place where we can witness the fruits of our labor (especially the impact ones).

So here then is my goal for my 27th year on this planet: Figure out how Openly can bring smiles to people’s faces, even if it’s just in little ways — because we provide them with the best customer service they have ever experienced, because animations in our application are cute, or because using Openly allows them to get work done faster and spend more time on the things that do make them smile (but even then, I’d love for Openly to directly cause little smiles to).

Dec 2, 2018 // 8:48pm @ Orbis House, Denver, CO, USA

I spent hours today working on the contract for working with our UI/UX friend Alex. About four hours, I think — and that’s on top of all the time I spent contemplating this for the past few days.

Why did it take so long? Not because of the contract. That’s fairly standard (we decided to build off a template provided by a website called Bonsai).

What took so long was identifying and writing down the precise scope of work: Which UI screens do we need? What form of documentation? Which image formats? Mobile or desktop? Or both? What process should we use? How many rounds of revisions? What information should be on each page? The list goes on!

Prior to now, we were working together without any precise guidelines. We had sent Alex a long list of screens that we need, with all the information and actions that needed to be on each screen. But other than that, not much was discussed. And, I believe, it led to bits of frustration: Alex was doing a lot of work, only for us to then ask him to change it. He could have saved quite a bit of effort if some of those details had been discussed upfront.

So here is a big takeaway: Clear expectations and boundaries are important. They help protect both Alex and us: Alex by limiting the number of revisions and requests that we could make and us by steering Alex’ work in the direction that will result in the end product that we need.

I had (mistakenly) believed that putting everything into writing would be overly formal, make the process feel transactional and artificial, and put restrictions on Alex’ creative genius. But yesterday, after putting everything on paper, he told me that having these clear guidelines in place actually motivated him. This does not appear to be unique to Alex: Looking at the research out there, there’s strong agreement that clear expectations lead to increased employee (or contractor) engagement.

I’m still a little unsure as to why exactly the clear expectations are motivating. If any of you know, please reach out. I’d love to learn!

Nov 30, 2018 // 12:03am @ Orbis House, Denver, CO, USA

Long day. Let’s just put it out there: TODAY WAS MAGICAL.

Reading that you might think that our lunch with Google Drive was a huge success. Well, it wasn’t. Or rather, our lunch was fine but our conversation really went downhill. We started talking and within 15 minutes, we had maneuvered the conversation into them recommending that we spend time really figuring out whether we’re trying to help social entrepreneurs (in which case, we should do something that actually solves their problems) or pushing a technology.

To be fair, they have a point. It’s just frustrating because it reminds me of most of our conversations last year and I had (mistakenly) believed that we had moved past this. Well, here we go again. This time, though, Jessy and I want to really figure out how to move beyond this. We have some ideas (more on that later).

A highlight from our conversation: They said they’d be happy to open up any API endpoints that we need 😲 AMAZING!

Lastly, I just had a really magical moment a couple minutes ago as I was drafting an email to one of the folks from Google Drive about the API endpoints we would like access to. I was writing about a feature that we would love to see added to Google Drive:

On another note, we’ve been looking for a way to give comment access to a folder + its files. For an Open Source project, comment-only access would be the perfect sharing setting. But folders only support view OR edit access. Our startup, Openly, is 70% open source but our files are view-only because manually setting each file to comment access is a real hassle. Is there a good workaround?

Anyone who’s tried to provide comment access to a folder & its files knows this problem. You can share folders with view or edit access only.

Sharing a folder via Drive UI )

So as I’m writing that email draft, I’m thinking that I should at least try this via the API:

Providing folder comment access via API )

AND IT WORKS! WOW. Our Openly Google Drive folder now in fact has public comment access! Comment away folks! Magic does happen :)

Mood: Enchanted… :)
Happiness: 5/5

Nov 28, 2018 // 11:16pm @ Orbis House, Denver, CO, USA

It’s already pretty late and we have our big meeting tomorrow — with the Google Drive team! So I’ll keep this short and go to bed soon.

We had various mentor meetings and meals today. I’m extremely grateful for all the people that are supporting us on a personal and professional level - we could not do this without them.

Here are the questions we ‘rehearsed’ for our meeting with the Drive team:

  • What do you want to get out of this meeting?
    Establish a long-term relationship & hear their thoughts on open collaboration
  • How can we be helpful?
    Connections, advice, mentorship
  • What kind of connections do you need?
    Product managers, technical writers, engineering teams — anyone who works at the intersection of tech and business or tends to collaborate on documents with a group of people
  • How much money do you need?
    We have enough money to cover our living expenses for the next ~ 6 months. We are not sure if we should raise money to hire a third person (full-stack developer). Pro: faster development. Con: huge investment ($$$ and time), very risky.
  • Why did you start Openly
    To bring open collaboration principles to the social impact space

A question that we need to make sure to ask Google Drive about is whether they are interested in copying our product (since one of the most frequently voiced concerns is that Google will build a similar product to ours and outcompete us)

Mood: Excited (for our lunch with Drive)
Happiness: 7/5

Nov 27, 2018 // 10:21pm @ Orbis House, Denver, CO, USA

Jessy got three people to request early access via our form today. Wooho!

I’m gaining ground on the contributions/pull requests feature. Users can now create pull requests, which copies over all files from the last commit, and then browse through files. Next, I need to refactor some of our application logic and then add force-syncing & file restore for contributions. And then review & accept/merge and discussions.

Last but not least: Antler told us that they finally submitted our EntrePass application. It could take up to eight weeks. Fingers crossed that it will process in time!

Mood: Excited for work tomorrow!
Happiness: 6/5

Nov 26, 2018 // 10:24pm @ Orbis House, Denver, CO, USA

After a slow period (due to all the guests we have been hosting + Thanksgiving), we’re now getting back into the grind. Jessy recruited some more potential users today.

We’re now at 10 users although we don’t have anyone actively using our platform. It’s a problem. We’d really like to find one active user before the year ends and I’m not sure if that’s going to happen if things continue the way the are. So… let’s step up the game!

Mood: Eager to find that 1 active user!
Happiness: 4/5

Nov 25, 2018 // 10:23pm @ Orbis House, Denver, CO, USA

Pull requests are starting to take shape. We have index and create actions implemented as well as the setup of the pull request (we need to copy all files from master branch into a new fork and provide the pull request creator with edit access).

We now need:

  1. files tab for browsing folders & files (without capture changes button)
  2. review tab for seeing the list of changes & accepting (merging) it
  3. discussion tab for discussing the pull request

In other news, the domain name has been renewed (it had expired a couple days ago, but was still far from being open to outside purchase [read more about the domain lifecycle]) . That’s bad news. The good news: The domain owner has replied to our email. He called our offer “not terrible” (whatever that means… :)) and said that he would get back to us soon.

Nov 24, 2018 // 10:30pm @ Orbis House

Today, I started working on pull requests. We’ve got a long way to go.

Happiness: 3/5

Nov 23, 2018 // 10:13pm @ Orbis House

It’s been Thanksgiving week, so not much is new. On Monday, we set up our analytics dashboard to help us track usage of Openly.

Now, we have more or less three weeks left before Jessy and I both take off for our respective homes. We are focused on bringing 10 more users on board and launching the pull request feature (which has been highly requested).

Mood: exhausted x_x (still recovering from my camping trip this week)
Happiness: 4/5

You can find older journal entries here.