via Mpumelelo Macu on Unsplash

Starting from the middle

I had an idea for a new app I wanted to make. This would be my first time building something on my own, from scratch. No cofounders like last time? No problem. Let industry best practices guide me along rather than a living breathing human at my side.

I’d followed the Lean startup methodology in the past — my cofounders and I looked to it when we built Riskopy. We found the general principles invaluable. But with so much to do and so little time, it wasn’t always a front-of-mind priority to put together a perfect process.

Now that we’ve sold the startup, I’ve been taking some time this summer to focus on projects of my own. It seemed like an excellent exercise to build something new and make process my top priority.

My goals were to…

1. Use the Lean startup methodology to iron out a product development process. Design it to apply to future work. Follow it to the letter.
2. Start — and finish! — building something cool. Use it to brush up on skills and technologies I want to keep improving in. Document the process to improve my writing.
3. Put something out into the world that adheres to my metrics for success:

• it’s helpful to its users
• it’s a pleasure to use
• it’s financially self-sustaining

I’m pretty location-independent. For several years I didn’t live anywhere long-term, but hopped from sublet to Airbnb to the occasional friend’s couch. (Hi from Edinburgh!)

(basically.)

In my experience as a traveler, I’ve come to identify a few things I need to know every time I arrive someplace new. Think of the info you find on the inside cover of a guidebook, but more practical and up-to-date.

I searched for a site that curated all this information. I’d come to rely on a few good ones that provided several of the details I was looking for. But they were designed for planning a trip, not for helping you out when you’re on the ground in a new place — jetlagged and out of your element and wondering if that fixed taxi price to the city center is a total rip off.

Normally I spend a couple hours Googling what I want to know, save it in a note on my phone, and carry on. I’ve done this so often that I know what I need to be looking out for. But I learned this through a lot of trial and error over the years. If I built something that automated my research, maybe it could help other travelers, too.

According to Lean, you must test and iterate on every assumption you make as you build the product. At this point, all I had was a problem I’d identified and an idea for how to address it. So the first assumption to test, by necessity, was the assumption that others are also experiencing this problem.

Alright, time to test my hypothesis!

The wildly obvious approach seemed to be: Walk out my front door and ask people. I’m in one of the top travel destinations of the world! Surveying travelers should be like shooting fish in a barrel.

I wrote a survey to root out what I believed to be the minimum required details:

• are they an independent traveler, and if so –
• what resources do they use to prepare for a trip
• do these resources leave them feeling well-prepared when they arrive
• did these preparations pay off to facilitate a smooth arrival
• and are they likely to use a travel web app

If you’ve built something like this before, you’re already having a good chuckle at my expense. But if all this sounds fine to you, let me point out that I forgot two blindingly obvious points.

1. Surveys are the worst. Nobody likes them, not even the pretty Typeform ones with a baller color palette.
2. They also give you biased results, according to whoever studies this. (Behavioral scientists who study data science? Sounds exhausting.)

Turns out, what you actually need to build product is to actually build something.* I wasn’t building anything, I was analyzing my idea to death. I was avoiding uncertainty, while hiding behind my belief that by following a respected process, I was doing everything right.

So I abandoned my colorful little Typeform, rifled through the drawers of my Airbnb, found a marker and a stack of post-it notes, and banged out a UI on the closet door.

What I didn’t immediately recognize was the (very mild, but very real) fear of striking out on my own. Until recently, I’d been working with two brilliant cofounders who I relied on and supported in equal measure. Nowadays, I’m fully responsible for supporting and relying on myself. But I didn’t take that feeling too seriously. Compared to Riskopy, this project is completely low stakes — I’m just doing it for fun.

But by brushing past that feeling, I channeled it right into the heart of my goals for the project. If I felt shaky or unsure in my ideas and decisions, I could turn to the methodology. Data, testing, and iteration would give me all the answers I needed, right? Not really, they’re just tools to help me make a more informed decision.

Process isn’t a proxy for judgment.

Testing my first assumption lead to analysis-paralysis almost immediately. I was very much not cool with how this was going, so I paused to reevaluate my goals for this project.

1. Start — and finish! — building something cool.
2. Stay open to learning new things as you go.
3. Put something out into the world. Success beyond that is a cool bonus.

When your priority is great results, process can be the enemy of performance. Not to say I advocate disorganized or sloppy work. But I do advocate cultivating the self-awareness to know what trips you up — and how to minimize its impact.

A blank page can be paralyzing. Better to get something down without over-thinking it. Don’t analyze your blank page to death. You can always go back and start again from the beginning (if you must). This time you’ll be well-equipped with what you’ve already learned.

*Quick note on asking people if they want to use your product. I don’t believe it was necessarily wrong to take a measure of the market. But I’d already done the minimum here: I mentioned the idea to a few friends and they thought there might be something cool in there. That’s enough. Get to work.