Imperfect Takes Practice

Since quitting my investment banking job to start Treatings, the mantra “perfect is the enemy of done” has been chanted in my ear. Grizzled (mustached) startup veterans have warned of the trap of delaying product launch in pursuit of perfection, only to realize you’ve been building something people don’t want.

Sounds logical, right? Of course you suck up your pride and release unpolished products. Better to get quick feedback and iterate accordingly than release a beautiful app no one wants. I quickly realized how hard it is to embrace speed over perfection.

First, I had to forget what I learned in investment banking. Perfection was demanded (although never met) in the 80 page pitch decks we churned out. As lowly Analysts, we operated out of our PowerPoint bunker, sliding the deliverables under the door when completed. Let’s just it wasn’t iterative and “minimum viable product” wasn’t a term embraced by my bosses.

This quest for perfection wasn’t all that hard for me to overcome with Treatings. I quickly discovered that it’s not building a minimum viable product that’s difficult, it’s exposing it to public scrutiny. In my previous job, I never had to really stand behind the bullet point monstrosities we created because Analysts were rarely brought to client meetings.

In hindsight, the process of opening my Twitter account should have been a warning sign that I might have trouble systematically releasing early prototypes. I agonized over crafting my first 140 characters, imagining that you’re only as strong as your weakest tweet. Similarly, it was difficult to release our initial beta (which we later called an alpha, when realized that was allowed). In our minds, our prototype would be immortalized and people wouldn’t understand that even we weren’t content with the current iteration.

Each subsequent product release has become easier than the last, but it is still scary (note use of the word “release” rather than the more intimidating “launch”). The best thing to do is practice releasing imperfect work, whether it’s a tweet, blog post or web app prototype. Even now, I’m fighting the inclination to labor over each word in this post. So I’ll eat my own dog food and end here.

This post was originally posted on Medium

Mind the fundraising gap — What I Learned Building… →

As a first-time entrepreneur, I’ve thought a lot over the past year about the optimal time for a tech startup to raise money. “Thought” is t…

Check out my first post on Medium

The Comfort of Busy Work

There are many menial tasks that creep onto my to-do list every week. Some are non-work related, such as paying bills or the weekly call to Time Warner to ask why our Internet still isn’t working. Of course with Treatings there are administrative tasks to complete, email responses I owe people and other things that pile up.

While I lament these tedious tasks, I’ve recently come to terms with a dirty little secret: these chores are a guilty pleasure. I embrace them. I seek them out. Why? Because they’re layups. They’re easily definable and easily completed. I can write them down, cross them off…great stuff.

On the flip side, when those tasks are knocked out I’m back to navigating startup land without a map. It sounds obvious, but because every team/product/market is unique, there is no checklist or roadmap to building a company. There are certain things, such as incorporating, paying your taxes (didn’t need my calculator to calculate 30% of $0 revenue) that all startups must do, but other than that each startup must determine their own path, figuring out how much time to spend talking to users/potential users, building the product, wearing patterned socks, etc.

I imagine it’s a bit like climbing a big mountain. You can see the peak in the distance, but not necessarily the path to get there. Two visceral reactions to avoid are 1) being paralyzed by the daunting task of getting to the top and 2) pulling back and searching for easily completable tasks, which may provide a fleeting gratifying feeling but won’t provide any meaningful progress.

I think the best thing to do is to remember that most first-time entrepreneurs have no clue what they’re doing. For better or for worse, I’ve heard entrepreneurs who’ve built multiple successful businesses say that the feeling doesn’t go away. It makes it easier to focus on the next few steps ahead when you treat the end goal as a beacon, accepting that while there isn’t a visible, direct path, there are multiple routes that will reveal themselves through efficient experimentation. Disclaimer: my recommendation of experimentation applies to startups, not mountaineering.

Now that it’s 9:30am and I have a meeting-free day ahead of me to be super productive, I better check Twitter to knock out the unread tweets staring me down.

Ask Specifically and You Might Receive

I recently watched the TED talk, “The Art of Asking,” and thought it was great. The title is self-explanatory. This is hardly the first thing I’ve read/watched preaching the power of asking for help. Most articles on the subject highlight the limitless potential upside of making bold asks and the limited downside of being rejected by a flat “No.”

As my friends can attest, I’ve become more comfortable asking for help. Whether looking for an introduction, a meeting or feedback on Treatings, I’ve benefitted greatly from overcoming fears of imposition and rejection.

But, I’ve noticed that my “asks” sometimes lack in specificity. I’m guilty of falling into the trap of confusing ambiguity for politeness. Ambiguity is the enemy, because it puts even more of a burden on the person you’re asking for help to decode your request into an actionable step.

I should be more aware of this. We have spent a lot of time talking about the reason why every meeting proposal on Treatings includes a proposed time/location. In an introductory email, requesting a meeting AND proposing meeting logistics would feel presumptuous. Unfortunately, this creates friction in getting offline in the way of multiple back and forth scheduling emails. We don’t want to put the onus on the receiver to schedule the meeting. Instead, if they’re interested they are presented with a set of proposed meeting details, any aspect of which they can change.

I’m an idiot

I recently met with a woman leading talent acquisition, among other things, at a local company to learn about the recruiting challenges she faced. In a follow-up email, I thanked her for her time and asked if there was anyone involved in recruiting at other companies who she could introduce me to.

My perception of the request: I’m being open and not demanding.

How it must have looked to her: What am I supposed to do with this? There’s no specificity around the ideal person/company you want to speak with and no explanation I can pass along for the reason for this request.

Her response: If there’s anyone in particular in my network (LinkedIn, Facebook) you’d be interested to meet, don’t hesitate to ping me. 

Reading her kind response, I had a face palm, self-reflective “you idiot” moment. Whereas at first glance it might have appeared presumptuous or forward to search through her network for people with relevant experience, if I didn’t do that it would be asking her to.

Oops.

When to Roll the Dice in a Startup?

Anyone have the answer? Cliff notes to this post: I don’t.

In the first year of building Treatings we’ve been thrifty, to put it lightly. Whether it’s calling the NYU Library our office, calling the tower of terror our beds, or teaching ourselves the required technical skills to build the platform rather than outsourcing, we’ve been pretty cheap to keep alive. I feel as though this has been an asset to this point. But, I’m also wary of our penny-pinching ways. Our DIY approach has come at the cost of speed. It has of course taken us longer to build the site than if we hired full-time engineers or designers.

This is okay, because up until this point we have essentially been running a series of social experiments to determine the best way to connect people offline. If we felt like we had to have all envisioned features on the site, or the sleekest design, in order to get traction, that would be a red flag. I’d even argue that we have benefitted, as first-time entrepreneurs, by not having the ability/capacity to build everything we want all at once. We have to make sure we’re spending our time on high-leverage activities. We make it a point to first find out what we need to build, by talking to users, and then find out how to build it.

Now, after I’ve done the “our weakness is our biggest strength” thing, I will say that I’m aware that it might be difficult to shed this cheap skin and make big bets when the time is right. It’s not that I anticipate an imminent “bet-the-farm” moment, but soon we’ll need to get a little farther out over our skis and spend money to grow our team and scale the product. The difficult question is when…It’s like poker, where you never have perfect information. I’m not much of a poker player, but I do know that in any tournament, the ultimate winner is someone who has faced a few inflection points where they made bold moves that had no guarantee of paying out.

I don’t have a ribbon to put on this post, since I’m trying to figure it out, but I’m sure I’ll have more to say on this topic as we move forward. 

Eyes on the Prize

This past weekend I did something I wouldn’t recommend to anyone with a competitive mom who’s in better shape than they are…mother/son spin class.

Since the recent transition to bunk bed life, a gym membership was my spending splurge. Being a part of gym, I’ve decided to take advantage of the fitness classes. So, I can occasionally be found in a yoga class trying to touch my toes while 15 Gumbys are in the human pretzel, or in spin class getting yelled at by the ultra-fit, scary instructor du jour while women twice my age stationary bike circles around me.

Since my athletic mom was recently sidelined with a toe injury, spin is one of the few exercises she can currently do. So, of course she wanted to embarrass me by showing me up in a class together during her visit this past weekend. Mission accomplished.

Spin is interesting. It’s like most exercise classes where the level of pain is dictated by how hard you push yourself. But, unlike other classes, you can slack off without fear of public embarrassment. There is a resistance knob on everyone’s bike you are [too often] instructed to crank to the right to simulate a hill. What I quickly realized is that no one knows whether you’re following orders and increasing resistance, or just doing a little arm-twisting motion over the knob. What you do see are pedals feverishly pumping. It’s all smoke and mirrors. Seriously, there is techno smoke and way too many mirrors. But also, I [theoretically] could leave my resistance at zero and do my best Lance Armstrong impression while honest Abe Lincoln mom huffs and puffs away slowly going up the imaginary hill.

This is a bit like tech startups. There are tricks to make it appear you’re easily clearing obstacles. With Treatings we’re frequently faced with “red knob” decisions. It’s easy to focus on the outermost, superficial layer of our site to provide an appearance of activity and success. The more uncomfortable thing to do is to make decisions that may put us in vulnerable short-term positions but have the potential for long-term benefit. For example, do we introduce that new feature which will look incomplete and unpolished but could produce meaningful feedback from our members? It’s something we sometimes struggle with, but I try to stay focused on long-term goals…like the ability to keep up with my mom on a stationary bike.

 

Coding Adventures

A few weeks ago I started teaching myself to code. It actually doesn’t feel quite right to suggest that I’m “teaching myself.” Besides benefitting from Paul’s guidance, there are so many freely available resources that I feel like I have multiple teachers (Codecademy, Ruby on Rails Tutorial, etc).

Paul has been suggesting for awhile that I learn to code, or at least have a working knowledge of the framework Treatings is built on. I think I’ll shirk all responsibility and blame my initial resistance on my Economics degree at Vanderbilt. Namely, the concept of comparative advantage. I was taught that a country has a comparative advantage at producing something if they can produce it at a lower cost than anyone else. The theory is that countries should produce only the goods they have a comparative advantage in, and they should import all other goods and services. Countries that specialize and trade for what they can’t produce as efficiently can consume more of everything.

So, my thinking was that since the country Paulistan has the clear comparative advantage in coding, instead of being a JV coder I should specialize in other tasks. Here are the flaws in that thinking:

1. Very early in a startup, there aren’t many tasks outside building the product (talking to customers is another big one)
2. While product management doesn’t require the ability to write the production code, an understanding of the work required to tweak/add features is important in determining the highest leverage inflection points
3. I don’t need to follow in Paul’s coding footsteps. While he has been shifting focus to back-end database management, I can have a meaningful impact by diving into front-end code. Next time I have a revolutionary idea (capitalizing a letter or moving a button two inches to the right), I can do it myself

I don’t have a set coding goal. I will say I’ve been enjoying spending time on an activity where problems have actual solutions. I can spend hours writing website copy or drawing out wireframes, but it is difficult to evaluate progress because there is no “right” answer. On the other hand, with coding there is a right answer (often many of them), and it is rewarding to have that resolution.

Designer ≠ Hoarder

We are in the process of redesigning the Treatings website. While our focus is on a few areas of friction in the user experience, the entire site will be impacted. We’re lucky to be working with a great designer. In conjunction with her design process, we’ve been drawing our own wireframes so that we can pick and choose the best ideas from both of our brainstorming. This allows us to take full advantage of her expertise and fresh perspective while leveraging the user feedback we’ve received on our beta and everything we’ve learned working on Treatings for the last year.

Although we don’t have a mobile app, we’ve gotten in the habit of first drawing out wireframes for a phone-sized interface, then backing into web design. This has forced us to prioritize the information we want to display on each page, cutting out the noise of less-essential data that might fit on a larger screen. I was thinking about this because I just wrapped up my latest apartment move (4th in 4 years!) and noticed the parallels between moving into a smaller space and redesigning Treatings based on a mobile first approach.

During this most recent move, I was resolved (forced) to purge myself of things I didn’t actually use. This wasn’t easy. There was an emotional farewell to a santa costume (I may still have the wig). Books were tossed. I offloaded many suits. All of this should have been done earlier. Cramming these things in my closet or under my bed was crowding out much more important items I actually did use and wear, like my one-piece pajama suit. The takeaway for Treatings is that each non-essential sentence or feature makes it harder for users to efficiently navigate the site (discover interesting people and take the conversation offline as quickly as possible).

In designing a room or web interface, I’ve found that open space can be my own worst enemy. Each extra shelf nailed into the wall or extra pixel on the screen invites clutter and leads me to delay the treasure/trash decision. In actuality, the goal of a disciplined mind should be to design in a space vacuum (space isn’t the consideration, only essential content). But, while I await a disciplined mind, I’ll have to organize within the confines of a 10x12 shared bedroom and iPhone screen.

It’s a work in progress for me. Just don’t look under my bed at the guitar that hasn’t been played in a year.

Movin’ on Up

There I was, standing in the lobby of the NYU Library talking to Rosa, the circulation desk attendant. There had been a crime. 

The suspect: a vending machine

The victim: me

The offense: I was shortchanged $.50

Why was I in the library of a school I didn’t attend following a paper trail to reclaim $.50? Was this the world’s saddest dream?

Nope. Well yes, it’s sad. But it actually happened 10 minutes ago. I didn’t quite realize the absurdity of it until Rosa pushed those two dusty quarters across the table to me. But it’s the principle, right?! Can’t let the vending machine fat cats take money from the little guy. And I can call myself the little guy because it’s officially been one year since Paul and I quit our jobs to build Treatings.

We’ve written a lot about the product on the Treatings blog, so here I thought I would address a couple of the more elemental things we’ve learned over the past year:

Work space:

Initially upon leaving our jobs, we shared a desk in another startup’s office. While it was great to work around smart people, we realized office space was unnecessary at our early stage. Since Treatings facilitates casual informational meetings in coffee shops, we figured that’s where we should be spending a lot of our time. So, for the last 9 months, we’ve spent many hours working out of coffee shops, with the NYU Library serving as a backup work space.

We’ve learned a lot from the many people we’ve approached in coffee shops. For instance, we met an artist the other day in Starbucks who mentioned that she enjoys working in more public settings, like coffee shops, because people will sometimes see and ask her about her work. In this way, she’s met one accomplished artist who has since become a mentor of hers, as well as a couple of clients. On Treatings, we plan to allow members to showcase the work they’re particularly proud of and display an openness to speaking about it in person.

Our habit of spending a lot of time at our favorite coffee shops, approaching people to learn about what they do and get product feedback, has made us marked men (aka “campers” in java circles). I’d like to think the gallons of coffee we’ve purchased help our cause.

Technical skills:

Many of the hurdles we’ve faced in building Treatings have been related more to social dynamics than technology. We are a tech-enabled, but community-driven, platform. That being said, Paul’s technical expertise one year ago revolved mostly around his academic studies of computer programming as it pertains to music, as well as what he learned during his brief tech role on Wall Street. Since then, he’s enjoyed throwing himself into web-related code in order to develop our platform. Now, if only we had a designer…(good news, as of last week we do!).

There are so many free resources on the web that make it possible to teach oneself how to code. We’ve benefitted immeasurably from building Treatings ourselves rather than outsourcing. We don’t think it would have been possible to arrive at our current model by this time if we had had to translate our concepts to a third person, one far less familiar with the idea, to implement. Admittedly, I haven’t done a good job of taking advantage of these resources, but I’m working on learning front-end code to help where possible.

Upward mobility:

Paul and I have learned a lot in the last year, helped by countless people who have spent valuable time meeting with us, providing advice and feedback. We’d like to think we’ve grown a lot and have decided our sleeping arrangements should reflect this fact.

Feb-12 to Feb-13: Room-o-bed

Feb-13 to [?]: Bunks!

In the Market for Designer Genes

Web design is freaking hard. While design can be broken up into many subcategories, we mainly think of it in terms of visual (the aesthetic of the site-what users actually see) and user experience (how users interact with the product). We need help with all of the above for Treatings, but user experience (UX) is where we feel we have the most immediate need. It is something we are getting ready to invest a lot more time and resources into.

I’ve been trying to learn as much as I can about how to design simple and intuitive user experiences (if you want to chat, check out my Treatings broadcast!) This has been challenging. An obvious solution would seem to be to emulate those who do it best. In my high school jazz band (nerd alert!) the teacher would tell me to listen to the great jazz drummers and mirror them. I’ve found that this approach isn’t as easily applied to design, for a few reasons:

Great UX isn’t always [immediately] apparent

Most of us without a background in design don’t always notice good UX when we see it. Of course you can tell whether a product is pretty or not, but great UX happens behind the scenes. I read about a story of an iPad being placed in the hands of a child in Africa, who had never seen a computer, and they just started navigating around the screens easily. That’s great design.

Furthermore, even if you’re looking at a product you believe has great UX it is hard to bottle the reasons why. The best design is unobtrusive, minimal and relies more on an understanding of behavioral psychology than technology.

Great design isn’t a transferrable one-size-fits-all commodity

Creating intuitive user experiences requires an intimate understanding of who will be using your product and for what purpose. Since UX must be both unique to the problem you’re solving and consistent throughout, it makes it difficult to borrow UX elements from awesome products.

As if it isn’t hard enough to steal…er borrow from….products who are doing a lot better job of UX design than we do, I’m poisoned by the fact that I live and breathe Treatings 24/7. I am more immersed in the premise and product than members. So, things I might find intuitive, since I talk about them in my sleep (seriously, ask Paul), could make no sense to someone browsing the site for the first time.

That is why I’ve decided to stop trying to learn about design and am instead trying to find one of those Men In Black pens that you flash in someone’s face to erase their memory. I will use it on myself every day. Paul will spend the first half of every day reminding me who I am and why we share a bedroom. Then, I’ll spend the afternoon browsing the website (for the first time) telling Paul what’s confusing.

What could go wrong?