By Chris Poole

It’s been a long four year journey, full of highs and lows. I am simultaneously incredibly proud, and incredibly disappointed.

I’m incredibly proud of an amazing team and all that they have accomplished. Our most recent product, DrawQuest, is by all accounts a success. In the past year it’s been downloaded more than 1.4 million times, and is currently used by about 25,000 people a day, and 400,000 last month alone. Retention and engagement are great. And yet we still failed.

It may seem surprising that a seemingly successful product could fail, but it happens all the time. Although we arguably found product/market fit, we couldn’t quite crack the business side of things.

Building any business is hard, but building a business with a single app offering and half of your runway is especially hard (we created DrawQuest after the failure of our first product, Canvas). I’ve come away with new found respect for those companies who excel at monetizing mobile applications. As we approached the end of our runway, it became clear to us that DrawQuest didn’t represent a venture-backed opportunity, and even with more time that was unlikely to change.

I’m terribly saddened that this may spell the end for our wonderful community, but it’s my goal to use what little money we’ll have left after the wind-down to keep the service alive for another few months. However as of today the team has gone their separate ways, and our doors are effectively closed.

I’m disappointed that I couldn’t produce a better outcome for those who supported me the most — my investors and employees. Few in business will know the pain of what it means to fail as a venture-backed CEO. Not only do you fail your employees, your customers, and yourself, but you also fail your investors — partners who helped you bring your idea to life.

In my case, I am extremely lucky and grateful to be partners with people who are simply the best. What separates the best investors is not how they help you when you’re a rocketship, but when your ship is on fire and you’re venting atmosphere. In this case, our investors have demonstrated what sets them apart from the rest — they’ve supported me throughout the ups and downs, andespecially the downs.

With that said, life goes on, and the best path forward is not a wounded one, but a more learned and motivated one. I’m definitely not itching to start another company any time soon — it will take time to decompress and reflect on the events of the past four years — but I hope that if I do some day decide to pursue a new dream, I’ll be in a much better position to. After all, I did just receive a highly selective, four-year education for a mere $3.6 million dollars! (I find humor helps as well.)

As for what’s next for me, I honestly have no idea. This is the first time in four years I’ve been at a crossroads like this.

One thing I’ll be doing more of is writing about my experience. Partially because it’s therapeutic, but also because if there’s a silver lining in all of this (and there is), it’s that I can help educate others about a path fraught with hardship, but rewarding nonetheless.

I’m also particularly inspired by what Everpix has done by making so much of their story public, and hope many others will follow in their footsteps of radical transparency. I don’t wish to glorify my failure, but it’s certainly something I’d rather embrace than hide behind for the next five years.

On that note, if there are any specific topics you’d like me to write about, feel free to submit them via my Ask page. Or if you’d like to say hi in general, please don’t hesitate to e-mail me atmoot@4chan.org. Believe me — I’ll have a lot of free time on my hands these next few weeks.

Last but not least, to my team — Dave, Eunsan, Alex, Nick, Shaun, and Jim — I am eternally grateful. To my investors — Union Square Ventures, Andreessen Horowitz, Lerer Ventures, SV Angel, Founder Collective, Chris Dixon, and Joshua Schachter — I could not have done this without you.

And to everyone who has supported us over the past few years, from the bottom of my heart: thank you.

Today my startup failed: No soft landing, no happy ending — we simply failed was originally published in 10,000 Ways to Fail on Medium, where people are continuing the conversation by highlighting and responding to this story.

When facing the reality of a failed product and 3 months runway left of investors money, sometimes the best solution is to go to Thailand.

In early 2012 Thomas and I envisioned a future where recreational football players would use an app to share their matches with friends and family. All their history of achievements would be recorded that would become their online football identity.

Using mockup design we tested the idea at KB (football club in Copenhagen) with players and coaches. The response was very positive. So we gave ourselves three months to build the first version of the app and test with a group of teams.

At the time I could work full time as I just sold my previous startup. Thomas on the other hand was contracted at Scandinavia’s biggest deal site to upgrade their whole backend. A tall order for any hacker. So building this app on the side would not going to be easy.

As I started working in the morning, Thomas would join me after his work and code till late after midnight. Those three months I think he slept 4–5 hours each night.

Clear vision and validation ironed out

Pumodo was launched in App Store in mid April with 5 test teams. The feedback was promising and the data showed that each user would in average add 6.4 players to his team. A very good growth indicator.

Interviews showed that spectators really loved the idea to get live score notification from the matches they were unable to attend. The math was that each player had in average 3 fans so a team had 45 in total. Often only 5 people attended a match so there would be 40 friends and family at home wanting to be updated on that match. The key would be getting players to track their matches.

A Skype meeting with senior level guys at Adidas confirmed that we were on right track in regards to our monetization model. They were committed to launch a campaign in our app once we reached a specific amount of users.

Thomas and I had the proof we needed. He just finished the contracting assignment so it was perfect timed as he could go full time on the project.

We also decided to work on the app the next three months in Silicon Valley. We’d had never been there before and it sounded like fun.

There we also could test the US market that was among the top 3 in size in regards to active recreational football players.

Do or do not. There is no try

In August we left for Palo Alto where we were invited to stay for two weeks for free in a cabin build in a backyard. The host was an awesome guy we met a year before in Copenhagen and one of the most esteemed growth hackers in The Valley.

From the comfort of the backyard cabin we moved to big city San Francisco and faced the totally hopeless situation of finding a place to live. We survived the first two weeks by renting office space at Tradeshift and sleeping on their couches at night. Not sure if they ever found that out.

Finally we managed to get a 9 m2/97 sqft room through our Y-Combinator network. Rent $1,250. Dang! But since we had free office space from our friends at OneLogin, our burnrate wasn’t yet gone through the roof. But close..

We did the show and tell dance at Techcrunch Disrupt and DEMO. Networked at GigaOm RoadMap Con and YC Startup School. Got tons of advice. Met people with amazing experience. We felt we were in the nexus of entrepreneurship and innovation. And we probably were. But we also got tangled in the hype machine. Our business plan was changing every week. We went from focusing only on football to becoming app for all sports. Think BIGGER was the mantra.

It was like our feet never touched the ground.

Our market research showed USA would not become our main market. Too fragmented and unfavorable league structures. Europe would be our target.

So in November we headed back to Copenhagen just in time for the Danish App Awards where we were nominated for Best Sports App and Best Functionality. With our feet on solid ground yet again we won as Best Sports App. Sweet!

And since we had been contacted by Danish business angels interested in investing, we felt everything was going as planned.

Winter is coming

One of the biggest disadvantages with recreational football in Europe was the long winter breaks. In Denmark it was 5 months. I felt like Ned Stark facing many years of winter. It rendered our app lifeless and desolate. No live user data to use to improve the app as majority of our users were based in the cold north of Europe.

Trying to remain positive we saw it as an opportunity to submerge into our hack cave to build the next big feature.

We wanted to solve the lack of ability to compare players across different positions. Current comparable metrics were goals and assist. It was not possible for a defender and forward to compare fairly.

The solution was an universal score based on players abilities to compare and compete against anybody regardless of age, level or position in lineup. Kinda like Klout score just for football players. The bigger impact you have in a matches, the higher is your score.

Concept explained here:

Clubs were offered a widget that showed Team of the Week based on the players’ score and a leaderboard among the clubs players. We wanted the clubs to celebrate individual players weekly achievements with place on the clubs Team of the Week

The hypothesis was that if we can get a club to place it on their club page and promote it, the players would want to be on the weekly Team Of Week so they download the app and start tracking their matches.

This was our growth hack.

Getting as close to our users as possible

In April we closed a $180k angel round and hired our first employee, Anders as a frontend dev. He was a great fit. Skillful, curious and a football fan.

From the desire to be in close day-to-day dialogue with our users, we decided to move our office to a football club (B93) in Copenhagen that was 1,800 members strong. Our office had only smelly locker rooms as neighbors. Perfect!

We were basically living with and meeting our users every day.

The coding of these two features took longer than anticipated which meant that we would not be able to launch before the summer holiday that is from May to August. The breaks between season started to really become a huge problem. How had we not seen this coming?

We needed users to test the new features. So that summer we went on a 7-day guerilla marketing campaign at one of the worlds biggest youth football tournaments, Dana Cup. We made a special Team of the Day webpage for this campaign. Promotion was with flyers and posters.

Despite personally handing out 10k+ flyers only 3 teams tracked their matches. The morale was still high but concerns started to arise. No panic. Yet…

If a platform fails at encouraging creation, it breaks down

When the new season started we had convinced a handful of teams at B93 to start tracking their matches. It started well as the matches were tracked and the “Team of the Week” on the clubs webpage was generated.

But the conversion of teammates joining after invite was very low. After 2–3 matches the tracking stopped. Even those players who had been explicitly instructed by the club director to track, stopped tracking. We did multiple interviews with the players and the general response was “the idea is cool, but meh..”

We had created an Indifferent product. Oh, the shame.

Pumodo was a product where people wanted to consume the live matches, player data and history but players didn’t want to supply it. The reward wasn’t high enough compared to the effort.

But our biggest self realization was that we were not users of our own product. We didn’t obsess over it and we didn’t love it. We loved the idea of it. That hurt.

Coinciding with our time of woe, the Danish National Football Union announced they would launch a competitive live score app. With all their members already in the app it would get even harder for us to sign up users on our home market.

We had good ideas how to fix the situation but with 3 months runway remaining of our angel round and, once again, a 5 month winter break upon us, we needed radical ideas.

Further funding was not possible without a critical amount of active users and an proven product/market fit.

One does not simply pivot

Our conclusion was that if we would use remaining resources to try to fix Pumodo, the odds would be against us. Even with extended runway the winter break would make it very difficult to test and validate the new ideas.

So why not create a new football app build upon our current experience and code…

During the last year working on Pumodo we had noticed accelerated technology leaps in live tracking of pro football players during matches.

The ability to track and record 1,000+ live events per match created incredible rich data that nobody was utilizing properly. Live score services still served fans with simple and stale stat notifications in apps and on web.

So we looked at the market for live score football apps. No real market leader. But the market was growing fast as this seemed to be the last category that not yet migrated to mobile. We looked at some of the major apps and thought we can do much better.

But we needed more runway!

Extending the runway by bringing down expenses was the only solution. Denmark is not a cheap country to live and work in. Almost as expensive as San Francisco.

So moving to a much cheaper country made sense. We narrowed it down to Philippines, Indonesia and Thailand. After much consideration we chose Thailand as Thomas had a good friend who lived there and owned a small co-working space from where we could work and live.

As the dust had settled, we realized that this time we did not have to convince teams to input data. We could just buy it. Awesome!

From the ashes a phoenix arises

Four weeks later in mid November Thomas and I were on a plane to Thailand. Anders would join us later in January. We decided to bump Anders up to co-founder. He shared our passion for the new product, was prepared to take a drastic pay cut and we really liked him. Best decision ever!

The next months went fast. Our corner of the co-working space was quickly transformed into our new hack cave . We were spitting out code and design in a daze of strong coffee and thai Red Bull. The Pace was frantic and probably prolonged the jetlag with a week.

We didn’t care. This time we were building an app with ourselves as users. That just felt right.

We designed the ultimate football app and then scraped everything “nice” off. Left was a minimum viable product that could be build fast and get out in the hands of users asap. All hypothesis could then be tested and iterated on as we got feedback.

One thing we thought was missing among the other football apps was the ability to get notification for individual players. Get updates of just Zlatans achievements without following PSG.

This would become our unique value proposition.

Out of money but an awesome app richer

Last wages were paid end of March. As expected. With barely $1,000 remaining, it was time to get this show on the road.

On April 9th Apple approved version 1.0 of Champion.

We limited the launch to Thai App Store only. It gave us a contained environment to learn and iterate. To get users in the app we used most of remaining cash to buy cheap app installs through Facebook ads. We had 5 weeks left to test the app in before the football season ended.

30 days later we became no. 1 sports app in the Thai App Store.

Then Apple promoted us. Boom!

The launch had gone so much better than hoped for.

Out of money. Don’t care. We’re driven by the excitement of building, what we think, can become the best football experience on mobile. An app that empowers fans with great insight in players stats and history.

Soon it will deliver a live-score experience so powerful that we expect to see José Mourinho sneak peek at our app before making substitution decisions.

But right now we’re laser focused on the biggest football event of them all: The World Cup in Brazil. To celebrate this we will add some Easter eggs that maybe will ruffle some Uruguayan and Brazilian fans.

Hope this story can become inspirational for entrepreneurs when struggling with a failed product and end of runway.

UPDATE! Read next chapter here: When your startup runs out of money you only got 1 problem

PS. If you want to help us, check out Champion and, if you like it, share it with friends. Thanks!

A Startup Postmortem with a Happy Ending? ..in Thailand was originally published in 10,000 Ways to Fail on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Peter V. Therkildsen Schlegel

Blogging to a following of what is probably no more a few friends, colleagues and business acquaintances is in essence either self-promotion or — in this case — a public therapy session. I’m hoping, however, that an entrepreneur or two might find this post and see that the grief and suffering they’re feeling does not make them the only sobbing loser in the world.

My startup, Admazely, has gone bankrupt. It has failed. It’s over. Done. We ran out of funding and didn’t manage to raise more money.

I’m not writing this to get pity from anyone. Or to get even with anyone. Or to out anyone. Except for myself. Let me be very very clear: the failure that I’m writing about here is mine and mine alone. Were other people involved? Absolutely. Did their actions influence the outcome of Admazely? Sure. Was it their responsibility? Hell no! In the epic words of former Secretary of Defence, Søren Gade, the buck stops here.

I’ll try and find the energy to do a more analytical post mortem with root-cause analysis and everything at a later stage. But right now, I want to share how my failure felt. And feels.

Admazely began informally in early 2011. Officailly, I began working on it in May (on a spare-time and hobby basis it was a few months earlier but my definition of when you start working on a startup is when you start doing it full time).

My eventual cofounders, David and Sylwia, joined in August. Fourth and final cofounder, Søren, made his commitment in March 2012.

We raised a seed round in April 2012.

And we formally filed for bankruptcy in May 2013.

This is the story of how that ride felt. What it feels like to fail.

First signs
Having a startup is an emotional roller coaster from the outset. Constant worry about finding cofounders, potential competitors, raising money, designing a product, building it, marketing it, finding a sustainable business model.

To me, the basic feelings associated with it are very similar to what I’ve experienced in previous jobs. I’m an “all in” kind of person, so I’ve felt a lot of responsibility towards my employers and my career in the past. But let me assure you that it pales in comparison to having my own startup. It’s the same basic emotions but they get amplified by a factor of thousand.

I have interviewed hundreds of candidates for positions before founding Admazely. And sure, it’s been really frustrating when I couldn’t find the right person for the job. Or I’d be excited when I finally did. But interviewing people that I desperately wanted to be a good fit for Admazely, only to find out they weren’t good enough was misery. Finally finding someone, asking them to join and be rejected gave reason to fundamental self-doubt. Am I not the mythological founder that rock star people are eager to join and work for free for a fraction of the company?

But it’s also insane joy. When those amazing candidates agreed to join despite more lucrative offers from companies I admire and respect, I was exhilarated to the point of shouting and performing those celebratory scenes you only do when you’re pretty sure no one is watching.

Where am I going without this? Well, in the general direction that you get a little bit numb to pain. You teach yourself to shake it off as quickly as possible and move on. When a lot of shit happened in a short period of time, I’d go into a state of mild stress and depression. But I’d have to force myself out of it. That led to this slight numbness which in turn led to a certain degree of insensitivity to signals from the outside. Because I was forcing myself to ignore them in order to not go under in pain, stress and anxiety.

And that slight numbness meant that I probably wasn’t seeing any first signs of failure.

I obviously knew that we were fighting a multi-front war. We had a cash-out-date approaching from day one (end of April 2013). We had product problems. We had sales and marketing problems. We had people problems. We had process problems. Startups have problems. It’s a grind — that’s the nature of it.

So retrospectively I don’t think that I was seeing any obstacles that I couldn’t overcome.

Emotinal distraction
In February 2012 my wife, Kia, and I learned that she was expecting our first child. She was due in early October. Preparing for a baby takes up some emotional bandwidth. As it should. I’m pretty sure Kia thinks that it didn’t take up as much as it should have. Even writing the section headline “emotional distraction” makes me feel a little guilty. Was my son a distraction to my startup? I told myself I could just add bandwidth but that turned out to be false. So preparing for a baby diverted my focus a little. But actually it was just a little.

Kia gave birth on September 27 and that’s when the actual diversion of attention happened. For the last three months of 2012 I was doing a shitty job of being founder and CEO of Admazely. And an even shittier job of being a father and a husband. The latter is not the point of this post so I’ll leave it out. It’s probably the one I’ll feel more guilty about in the long run. The former, however, made me pretty aware that I started being one step behind on many things. I felt it and my colleagues felt it. It felt like failing at the micro level. It was a tough time.

During the Christmas holidays I decided to get one step ahead again and I kicked off 2013 with an all-hands meeting setting a stronger direction and honing up to my mistakes in the previous three months. The team responded really well. They all knew it and could feel that we’d been getting lost due to my lack of leadership. And the next 45 days were some of the most amazing in the two years that I was doing Admazely.

The big blow
As mentioned, our cash-out-date was approaching. We’d joined the Accelerace program based on a recommendation from our chairman and representative of our lead investor, SEED Capital. The program does a lot of good things. The reason we joined was that it has a loan option for program alumni companies. The people in the program has to recommend you, you jump through a few hoops, you pitch and negotiate and finally you present to their equivalent of the infamous partner meeting — the Investment Committee.

We had done all of it and everything was teed up for the Investment Committee presentation. The program manager, Jesper, endorsed us vigorously, the program consultant, Christian, who had worked with us was an enthusiastic ambassador. We had spoken bilaterally to most of the people on the committee and had received confirmation that they would support our loan application. SEED Capital had agreed to syndicate the loan, further endorsing it. Our chairman was on the Investment Committee (yeah that definitely could be seen as a conflict of interest but that wasn’t my headache) and had spoken to most of the members.

I had all of my ducks in a row so to speak. Or so I thought.

I went to present on Tuesday February 6 with confidence and less than two months of cash in the bank. It was snowing yet thawing. A disgusting day, typical Danish winter.

My presentation was ok. The mandatory Q&A afterwards was horrible. The only two people in the room that we hadn’t gotten prior support from were skeptical to say the least. As I left the room I was shattered. And as my contact at Accelerace didn’t call me later on that day I knew where it was going. My chairman didn’t either. Not a good sign. I left messages and they didn’t return my calls.

In the afternoon I had a speaking engagement in the other end of the country, pitching to a huge room full of potential customers. It was an absurd experience. I was crumbling on the inside but had to pose confidently. I had invited to of our customers to also speak at the event and after dropping them off I sat in the rental car staring at air. Crying. Feelings of fear, anger, self-righteousness and uncertainty overwhelmed me.

A million thoughts were racing through my mind. Guilt towards Kia for asking her to let me jeopardize our personal finances and then failing to pay back on her trust. Self-doubt. But it all just got worse from there on.

When Christian called Wednesday afternoon I knew the outline of the conversation before picking up the phone. I was oddly emotionally detached as we talked. Still kind of shell-shocked.

The worst part at this stage was telling my team the news. I had been 100% transparent about our cash situation and our process with Accelerace so they were expecting good news. I waited until Monday at the weekly all-hands. I should have spoken to them faster. Most of them knew me well enough to know what was up based on my mood and body language in the days leading up.

I told them that I would hustle to find other investors but that realistically it took more than the month-and-a-half of cash that we had left. Two and a half if we were all prepared to work up until a payday that we all knew would lead to bankruptcy, not pay. We all were, of course.

Piling on
December through March we were killing it in our sales team. After a lot of iteration we had finally gotten a small team in place that were converting leads into customers. The two core people on that team were Harriet and Nate, both Kiwis. A core element in my Hail Mary fundraising strategy was that we were finally getting sales traction and that we had found a model to build an international customer base through tele sales. Most Danish startups begin selling locally and then expand from there. We had chosen a pretty bold strategy (against the advice from our board) and gone for ‘instantly global’, meaning the bulk of our effort was in calling the UK. And for that you need native English speaking sales people. Hence my praise of Harriet and Nate (and Sophia, our Aussie sales supporter). We spend three months achieving what a successful startup like Trustpilot reportedly spent almost a year doing: making steady sales progress in the UK.

Mid-February — roughly two weeks after having our funding plan dissolve before my eyes — Harriet and Nate received news that they would not be granted permanent work visa in Denmark and were to leave the country within 30 days.

It felt like the most unfair thing that could possibly happen at that point in time. I had less than two months to raise about 3 mdkk with a pitch that now had zero chance of delivering if an investor should decide to invest. I remember closing my eyes when I got the news, laughing manically for like 10 seconds while just feeling dizzy. Harriet, Nate, Sophia and our “growth hacker”, Daniel, had been busting their asses off for the last few months trying to crack the code to making it all work. And right there and then someone in SKAT decided that what Harriet and Nate were doing did “not qualify as the kind of work that a Danish citizen could not perform equally well”.

What. The Fuck?!? I just couldn’t believe it. The eloquence, snappy responses, mastering of nuances within the language that makes a really talented sales rep is based on intimate knowledge of said language. Their skill set were not some that a Danish sales guy could pick up from learning English in school or even living abroad for a short while. I was flabbergasted. And I wanted to scream. But even at that point I felt the need to keep a straight face to the rest of the team. I’m pretty sure I didn’t manage. If only half the despair I was feeling shone through, I’m pretty sure my colleagues felt like packing up their shit and leave right there and then.

They didn’t. Maybe they should have.

As I thought things couldn’t get any worse, our CTO and cofounder, David, pulled me aside one day and told me that he and his fiance were moving back to Stockholm. It had been a long time coming. His fiance couldn’t get settled in Malmö and wanted to go back. David had been postponing the decision but had finally chosen not to jeopardize his relationship. A good decision and one in which I support him 100% as a friend. As a cofounder — I found his timing to be the worst possible.

Anyone who have seen a cofounder leave their startup knows the feelings flying through my head at that point. Betrayal, sorrow, shock. Loneliness. Until that very moment it had felt as if David was the one person that would stay with me until the very end. But that wasn’t the case now. The weight on my shoulders already felt heavy but it just got a lot heavier. And I knew that even if we did manage to raise more money, we couldn’t realistically continue our upwards trajectory. Development speed would decrease dramatically and the driving force in getting shit done would be gone. No sales team and no CTO.

I still struggled to keep a straight face to the rest of the team, to my board, to customers and suppliers and to potential investors. And it seems I half-managed. But only half-managed. I didn’t crumble completely on the surface but underneath it was the most taxing time of my life.

I probably went and pitched somewhere between 10 and 20 potential angel investors after this point. And my pitch got weaker and weaker. Because I had lost faith myself. I remember one meeting in particular that our chairman, Niels Vejrup from SEED Capital had helped tee up. It was with Jesper Buch and Ditlev Bredahlwho had been dancing in the shadows for a while and were now ready to talk. It was a Skype call and I had tried to prep for the meeting. Tried to find ways to frame our situation that would appeal to their hands-on approach to angel investing. Especially Jesper is known for investing heavily in the team and the founder(s). Which would -under normal circumstances — be great news. I’ve pretty consistently gotten good feedback from both VCs and angels. But this time I sucked in a major way. As I was pitching I knew I sucked. I felt like a dog that has been beaten to the point of scared submission. And I acted the role of a loser. Because I utterly felt like one. That meeting was an image of how I felt at the time and how my performance suffered from it.

Anyway — the list of potential investors got shorter and shorter as I got the ‘thanks but no thanks’ emails and calls.

Bankruptcy
We had a board meeting on May 14th 2013 where we formally decided to file for bankruptcy. I filed the paperwork, helped the lawyer, etc.

The morning after filing the papers, we all cleared out the office. Not much was said except for the occasional half-hearted joke trying to lighten the mood. We agreed to meet for a piss-up a couple of weeks later when the smoke had cleared.

It was two weeks of extremely ambivalent emotions.

On one hand I was crushed. Watching two years of my life go down the drain cannot be described to someone who hasn’t felt it.

But on the other hand I felt tremendous relief. Finally, it was over. Having known where it was heading and trying to stop us falling off a cliff was unbelievably tough. Fighting with all I had knowing that our faith was in the hands of someone else and that we needed something in the proximity of a miracle. Albert Camus writes in his self-proclaimed main work, The Myth of Sisyphus, that Sisyphus is only set free as he accepts and embraces the absurdity of his destiny. I tried to do that but didn’t manage.

When I had filed the papers and we were officially bankrupt and I wasn’t allowed to touch anything I felt relief. Relief that my struggle was over. Relief that finally I didn’t have to get up in the morning, put on a brave face and lie to everyone around me.

And I felt shame. Immense shame BECAUSE I felt relieved. I was supposed to only be devastated. I was supposed to not have given up. The common narrative of startup founders is the one in which the founder overcomes. Where he endangers the financial health of himself and his family. Where his 20 credit cards are maxed out when he finally gets funded. I felt ashamed that I had given up too soon. That I had kept my promise to my wife and not gone beyond the financial limit that we had originally agreed. Ashamed that I had only spent half our life savings on my failure and not all of it. Logically it’s nonsense but the narrative that’s been created around startup life — one that I have bought into as well — is one of relentless pursuit.

Sure, we had endured some hardship. Our first office space had leaky windows and no heating. Our desks were old garden furniture that I had borrowed from a friend of mine. We didn’t pay any rent, instead I would clean the kitchen of the shared office space that we were in. To cut personal living cost for us all, we ate lunch leftovers from one of the more established companies in the building and in return I did the dishes for the entire building. David rented a scrappy room in Malmö and occasionally took a weekend trip to Malmö to see his girlfriend. It wasn’t that we were too posh to endure hardship.

But it still felt as if we should have done more. And shame still consumes a lot of my emotional bandwidth when I think back on Admazely.

Aftermath
I guess shame was also a major driver of my behavior in the past few months. I was afraid to admit my failure to the world. Afraid to tell people that we had gone bust. Publicly admitting it was like crossing into a whole new dimension. I had a lot of psychological equity invested in my identity as a startup founder. Now, I was just a bum without a job.

My friends would tell me to give it time and think about what I wanted to do. Don’t rush it, they said. Well, there were more perspectives to it than that.

First off, there was nothing else I wanted to do. Maybe another startup at some point. But right there and then the idea of taking a job was inconceivable. I waded through job sites and talked to people and I simply could not get excited about anything.

Secondly, there was the responsibility to my family. I hadn’t gotten a salary for a couple of months and my wife was on maternity leave — which despite Danish welfare left us with a gross monthly household income of around 14,000 Danish kroner. In other words, we were once again digging into our savings to pay the bills. So I needed to get off my ass and generate some kind of cash flow.

Right around that time Martin Bochineck who was an angel investor and sat on the board of Admazely called me. He had had a front row seat when I lost a chunk of his money. Martin is one of the most decent and gracious people I have ever come across in my business life. I have witnessed it first hand and I have numerous accounts from others who have had similar experiences. Martin has a moral integrity that is extremely rare. I owe a lot to him as he helped me cope both during and after my failure.

He offered to pay me a salary equivalent to my CEO salary in Admazely (which admittedly was pretty negligible) to come in and “help him out with stuff for a few months” while the dust settled. I had my doubts since I simply didn’t feel as if I had anything to offer at that point in time. But I eventually accepted. And that’s how I’ve ended up at Magnetix. It’s a great place with very talented people. My role here has become more permanent. I do what I did five or six years ago, handling client accounts and overseeing projects. It’s familiar ground and something I know I do well. It’s something I can do without investing my soul in it and still excel.

Will I be doing this the next five or ten years? Probably not. But for the time being, it’s nice being around smart people doing great work. It’s a privilege to be part of a very successful company. To be able to contribute at a pace that suits where I’m at emotionally.

Failure sucks monumentally. For a founder failing it needs to be ok to talk about how much it sucks. Both the small failures along the way and the huge ones that are definitive. Failure hurts emotionally. If it doesn’t, you’re either not really invested or simply a shallow person lacking the ability to reflect on what you’re doing. My failure has cost people money, it has put people’s personal relationships at risk, it has put people’s financial situations at risk and it has cost a lot of my personal credibility. I don’t celebrate failure, i hate failure.

I’m still recovering from my failure. Some nights, suffering from occasional insomnia, I still sit alone in the living room thinking about what I could and should have done. My failure still haunts me and I suspect it will for a long time.

Ramblings of an Entrepreneur was originally published in 10,000 Ways to Fail on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Greg Linden

This is the end of my Starting Findory series.

Findory was my first startup and a nearly five year effort. Its goal of personalizing information was almost laughably ambitious, a joy to pursue, and I learned much.

I learned that a cheap is good, but too cheap is bad. It does little good to avoid burning too fast only to starve yourself of what you need.

I re-learned the importance of a team, one that balances the weaknesses of some with the strengths of another. As fun as learning new things might be, trying to do too much yourself costs the startup too much time in silly errors born of inexperience.

I learned the necessity of good advisors, especially angels andlawyers. A startup needs people who can provide expertise, credibility, and connections. You need advocates to help you.

And, I learned much more, some of which is detailed in the other posts in the Starting Findory series:

In the beginning
On the cheap
Legal goo
Launch early and often
Startups are hard
Talking to the press
Customer feedback
Marketing
The team
Infrastructure and scaling
Hardware go boom
Funding
Acquisition talks

I hope you enjoyed these posts about my experience trying to build a startup. If you did like this Starting Findory series, you might also be interested in my Early Amazon posts. They were quite popular a few years ago.

In The Beginning

The fundamental idea behind Findory is to apply personalization to information. Help people deal with information overload. Help cut through the noise and filter up the good stuff. Help people find what they need.

Personalization can do this using implicit information about your wants and needs, learning from your behavior. Personalization complements search. Search requires people to explicitly provide a query. Personalization surfaces useful information without any explicit query.

Personalization can also be used as a way to improve search. For example, if people are repeatedly refining a query (e.g. [greg linden findory], then [greg linden amazon]), they are not finding what they need. Paying attention to what they have done, especially what they have done recently, and showing different search results to different people can help surface information that otherwise might be buried deep. That is also personalization.

In addition, personalization can be used to improve advertising. Almost all advertising is useless, and annoying. Advertising does not have to be that way. Advertising can be useful information about products and services you might actually want. By paying closer attention to your interests and needs, advertising can be targeted instead of sprayed. It can be relevant and helpful, not irrelevant and wasteful. That is also personalization.

Back when I became really interested in this and wanted to work on it, I was just getting out of Stanford in 2003. Creating a company was not my first plan. I talked to Google, Yahoo, MSN, and Amazon first. The people I talked to expressed interest, but not urgency, and did not want to move as aggressively on personalization as I did.

I believed in the value of applying personalization to information. I wanted to see it happen. While I thought it was inevitable that everyone will be doing personalization of information over the next 5–10 years, I wanted to see it sooner. I started Findory to make it happen.

On The Cheap

When I started Findory, I was extremely sensitive to burn, probably too sensitive.

Maybe having witnessed all the dot com flameouts caused me to be overly cautious, but I wanted to be very careful about money flowing out the door. Many companies do fail early simply by running out of cash. I thought the best way to avoid this was to be careful about spending money.

Findory was built on the cheap. It is self-funded. There is no office space; the company is virtual. There is almost no marketing or advertising.

There are no salaries or benefits at Findory. For most tech startups, salaries dominate the burn rate. Even at 1/3 salary, each additional employee is about $4–6k/month (fully loaded, includes benefits, expenses, office space, etc.) At full salary, it is about $10–15k/month. Salary and benefits would have burnt through initial funding in less than a year.

By the way, it is worth noting that not drawing a salary is roughly equivalent to taking a salary but investing an equivalent amount immediately back in the startup. The latter is a lot more complicated, but both serve to fund the company using the money normally paid in salaries and benefits.

Findory uses free open source software (Apache, MySql, Linux, Perl, Berkeley DB). This allows the company to keep its costs low in its infancy. A quick note here, using Fedora Linux was a mistake. As it turns out, the upgrade path to get patches on major releases (e.g. Core 3 -> Core 4) is quite painful.

Findory uses cheap, leased, commodity servers. Findory currently runs on six servers. The cost per server is under $100/month. They are simple, low end, AMD boxes with a reasonable amount of memory and a cheap IDE disk.

Rather than pay for a news feed, Findory runs its own crawl. That allows us to customize the crawl to our needs and quickly launch new products (e.g. video, podcasts), but does take a fair amount of time to maintain and extend.

In retrospect, I think I have been too cheap. The tradeoff here is between death by burn versus death by resource starvation. While Findory has lived a long time with very low burn, it has been starved of resources, slowing growth and making it difficult to pursue many paths for expanding the products.

Legal Goo

Startups have to do a fair amount of legal goo. Finding a good lawyer is important not just for legal advice, but also business advice and contacts.

It is hard to find good lawyers. If you can, try to find someone with substantial startup business experience in your sector (e.g. internet startups). Talking with someone who understands your business, is excited about it, and can offer parallels to others is extremely valuable.

Unfortunately, legal work is extremely expensive. $400+/hour is not uncommon. While many law firms will delay billing for small startups and may even write off some of the work, lawyers can do major damage to the burn rate.

Even simple things like assisting with negotiating an NDA can cost a few thousand dollars. That can be annoying. Folks at large companies you might be talking to think of legal work as costless or, at least, cost is unimportant. So, biz dev people at big companies are happy to play games all day long with you with legal agreements.

But, in these discussions, each time your little startup needs to turn to your legal team, you rip through the nest egg. More substantial legal issues may cost enough to even threaten the life of a startup.

On the issue of intellectual property protection, Findory did seek patents, but I am not sure I would recommend this path to others. Filing was expensive ($10k+) and extremely time consuming, stealing time and money away from building products, helping customers, and innovating on the core engine. Even worse, I now fear that patents provide little protection for a small startup. Not only do they take years to issue, but also they cost at least $1M and several years to attempt to enforce; clearly that amount of time and money is impossible for a small startup.

There are a few other pieces of legal goo I will comment on briefly. Watch out for conflicts of interest with bigger clients of the firm; Findory lost its first two law firms suddenly and inconveniently when they bailed due to conflicts of interest. Choose your incorporation carefully; LLC or S Corp provides tax advantages, but you need to be C Corp to take some types of funding, and converting can be a bit of a pain. Put reasonable terms of use and privacy policy pages up on your website. Grab related domain names; I neglected to get a common misspelling for findory.com — findery.com — which still causes headaches sometimes. Make sure your intellectual property and ownership agreements are in place for anyone who does work for your firm, including your contractors.

Overall, looking back at my experience, I think a mistake I made in the very early days of Findory was thinking too much of law firm as a mere source of legal advice. In fact, the most valuable interactions with our lawyers were the business advice and connections they provided. Despite the cost, it is worthwhile to find one that can advise you on all aspects of your business.

I want to end by emphasizing that it is important to understand that any business discussions with any large firm are going to be costly for a startup. Not only do you have the risk of disclosing information (regardless of NDAs) to a potential competitor, but also the cost of any legal frameworks necessary for the discussions can be risky for a tiny startup to bear. Be very careful with who you decide to talk to and make sure those discussions are worth the cost.

Launch Early And Often

When I was at Amazon, I was a strong believer in the idea of launching early and often. In our group, new features typically launched in weeks, then were modified repeatedly. Often, projects were completed in just days. Projects spanning multiple months were unusual.

I carried this philosophy over to Findory. Findory was built on rapid prototyping and early launches.

When Findory first started, the company was targeting personalized web search.

A quick prototype revealed the need for more data about user behavior. The recommendation engine reached out to ask, “What have other users done?” and always got the answer, “I don’t know.”

For a brief time, I looked at whether I could acquire the necessary information about user behavior. Were there old weblogs available from major search engines (without restrictions for commercial use)? Would Yahoo consider a deal to share an anonymized sample of their logs? Could I acquire logs from an ISP (as Snap.com later did)? No, no, no.

With some amount of frustration, I abandoned this web search prototype and switched to news. With news, bootstrapping is a bigger issue. Old news is no news, as they say. The advantage some may have from massive amounts of log data is diminished by the need to a good job handling the cold start problem.

I spent some time prototyping a personalized news application. I iterated. Eventually, it looked good in my tests.

I decided to launch Findory.com as a personalized news website in Jan 2004. At that point, Findory did not have its own crawl. Findory did not even have a search engine. But the personalization worked. I iterated on it rapidly over the next few months, launching new versions nearly daily, including a Findory crawl and a custom news search engine.

In June of 2004, I launched a version of Findory for weblogs. The underlying personalization engine had to be adapted for blog articles, articles that are often short, almost always opinion, and frequently crappy. Several iterations on an internal prototype tuned a version of the engine to the characteristics of weblogs. A crawl had to be created to cover the most interesting and useful weblogs. Tools were needed to process new weblogs and filter out spam weblogs (splogs).

With Findory and weblogs, I made the mistake of launching as a separate site called Blogory. It was a foolish decision and one that later would need to be reversed. Blogory is now merged into Findory.

Over the next many months, we iterated, iterated, and iterated. There were several redesigns of the website, all looking to figure out what format worked best for readers.

In May of 2005, personalized advertising launched. Findory’s advertising (which is sourced from Google) is targeted by Findory not only to the content of the page, but also to the specific history of each Findory reader. Findory focuses the ads both based on what each reader is currently doing and on what that person has done in the past.

Now, in 2006, Findory has many products: news, blogs, video, podcasts, advertising, and (alpha) web search. Findory is personalizing information in many different areas.

Looking back, I think a few things are critical for a strategy of launching early and often.

First, you need developer websites, a full testing environment where programmers have a toy version of the website with which they can tinker. To iterate and test, you need to see everything working together in a sandbox environment.

Second, you need some objective test of the ideas, some measure of what is good or bad. You need some way of evaluating the prototypes even if it is not ideal.

One important point is that not all prototypes should be launched. Yes, I know, you worked hard on that thingie. But, many things should be throwaway, just experiments. At Findory, many things did not look good during testing and were abandoned. They were a path not followed. That work is still valuable, mind you. We learned what works and what does not work. That information is valuable even if the feature was discarded.

Finally, I want to point out that the strategy of launch early and often is not without cost. It is true that some people and press looked at early versions of Findory.com and saw things that were still really prototypes. Sometimes, they judged it harshly and never returned. That has real cost. The damage to the brand is not insignificant.

I remain a strong believer in launching early and often for web development. Findory is learning constantly. We get immediate feedback. We get rapid gratification. The benefits far outweigh the costs.

Startups Are Hard

There is no doubt about it. Startups are hard. You have to do everything — and I mean everything — yourself.

You have to do all the technical work, including prototyping, research, coding, web development, design, data analysis, metrics, system administration, networking, hardware procurement, and database administration.

There is marketing, including advertising, press relations, viral campaigns, framing the product, and pitching to influencers.

There is business development, including handing requests for technology licensing, talking about cross marketing deals, exploring feed licensing, and investigating partnerships.

There is management, including project management, building a culture, choosing founders and advisors, hiring, mentoring, setting expectations, and building teams.

There is legal, including creation of and modifications to the corporate structure, non-disclosure agreements, licensing agreements, employee incentive packages, patents, intellectual property assignments, and frameworks for partnerships.

There is finance, including accounting, taxes, licensing, managing cash flow, business planning, and pitching potential investors.

There is customer service, including building help pages, creating customer self-service features, and handling incoming contacts with suggestions, complaints, requests for information, and requests for help.

All this for incredible risk. Often, it is your own money being poured into the company. There typically are no or limited salaries and no benefits.

That incredible risk comes with many rewards. Though unlikely, there is a large potential payoff dangling off at the horizon. Startups are building something new, the exciting tip of the cycle of creative destruction. And, running a startup, you have much freedom in what you decide to pursue.

However, that freedom can be a curse. There are so many degrees of freedom, it can be overwhelming.

What should the company do? Even more important, what should it not do? Does it have enough money to pursue X? Can a competitor better implement feature Y? What really matters to the company?

There are so many options, but so little time. You must keep moving, keep making decisions, but always be willing to stop or reverse if something looks wrong.

You learn a lot, but it is incredibly difficult. It is a remarkable challenge, an incredible experience.

Talking To The Press

I wanted to do a piece on talking to the press. I am a tech geek, not a marketing dweeb, so talking to the press is not my strong point. But, having been forced to do it, I think I have learned a few things.

The biggest thing I have learned is to focus on what reporters want. It seems to me that reporters are looking to write a solid, interesting story, supported by good sourcing and strong quotes. A typical story seems to consist a few paragraphs of explanation followed by some quotes from someone that express an opinion on the reporter’s explanation.

My strategy is to only try to make a few key points. I try to say a few things that describe my impression of the overall situation, intending that piece to help with the explanation that is in the reporter’s own words.

Then, I try to give just two or three pieces of opinion, my view on the situation. At this point, I try to talk slowly and carefully, keeping in mind that the report probably is trying to transcribe an exact quote. Sometimes, I repeat the quote or something fairly similar to the quote.

One other thing that I have found important is that reporters do not always ask the questions you think you they should. That is okay. You can usually take a question that you may feel is poorly chosen or misdirected and simply answer a variant on it that is the question you thought should have been asked. That variant is just as likely to make it into a quote as a more directed answer and may be more appropriate and more useful to the reporter.

Finally, I have found that most press coverage of tiny, little startups like Findory will be positive. After all, if they were going to write something negative, they would not bother writing about Findory at all. Yes, being ignored is an issue, but it is good to know that, when you are talking to the press, if you get any coverage, you are likely to get fairly positive coverage.

Maybe it is working on a news site, but I tend to have a lot of sympathy for the press. I think reporters are struggling with a difficult job and try to help them as much as I can. However, helping reporters is not a selfless act. The more helpful I am, the more likely it is that I get in the story, and any mention of Findory may benefit the company.

Customer Feedback

Findory customer service is light, averaging a couple e-mails per day. They are mostly suggestions, a few requests for help, and a few complaints.

Of the few complaints, the most common are various forms of rantsabout either liberal bias or conservative bias. Partially this is due to our political climate right now where any site at all related to news is bombarded by absurdity from the extreme fringes.

However, accusations of bias also may be due to Findory explicitly trying to not pigeonhole people. The idea of personalized news has been around for a decade or so. One common criticism of the idea is that personalization may pigeonhole people, showing them only what they want to see. On Findory, opinion articles are not selected based on a particular view, with the result that people are exposed to viewpoints they might prefer to ignore.

It is an interesting question whether Findory should have given people what they wanted — let people put on their blinders and pigeonhole themselves — or if it is doing the right thing for the long-term by helping people discover a breadth of information and viewpoints.

On the requests for help, the most common is somewhat amusing. People often expect Findory to be harder to use than it is. It surprises me, but some write in and ask, “How do I set it up? What do I do?”

Perhaps Findory is too simple. “Just read articles! That’s it,” I often say. “Findory learns from what you do.” Everyone has been trained to expect sites to be more difficult — lengthy registration and configuration, for example — and it appears it can be confusing when all those barriers are removed.

On the suggestions, the most common are requests for a feed reader (which we did as Findory Favorites), interest in rating articles and sources (which we have prototypes a few times but never launched because it seems to change the focus away from reading), a desire to see news photos inline on the page (potentially costly, but something we are exploring), extending the crawl (always working on it), and support for non-English languages (prohibitively expensive due to the changes required in the recommendation engine).

Customer feedback is useful. Many Findory features have been implemented as a direct result of suggestions from Findory readers.

However, just listening to customers is not enough. Customers will tend to suggest iterative improvements and request more features. Customers will not offer ideas for big jumps, big ideas, or major new products. Customers will not balance requests for new features against simplicity and usability.

When looking at customer feedback, I find it is important to look beyond the words to try to divine the intent. The best solution may be something completely different than what was suggested.

Marketing

Ah, marketing. Is there anything that techies like less?

It is obviously naively idealistic, but I think we geeks wish marketing was unnecessary. Wouldn’t it be nice if people could easily and freely get the information they need to make informed decisions?

Sadly, information is costly, and the time spent analyzing information even more so. People generally do use advertisements to discover new products and rely on shortcuts such as brand reputation as part of their decision-making.

As much as we might hate it, marketing is important.

Marketing also is absurdly expensive. It is mostly out of reach for a self-funded startup. Though I recognized the need, Findory.com did almost no traditional marketing.

There were limited experiments with some advertising. For the most part, these tests showed the advertising spend to be relatively ineffective. The customer acquisition costs came out to a few dollars, cheap compared to what many are willing to pay, but more than a self-funded startup reasonably could afford.

Even without substantial advertising, for the first two years, Findory grew at about 100% per quarter. Most of this was from word of mouth and viral marketing features.

Findory tried to accelerate word of mouth by focusing marketing time and effort on PR with reporters and bloggers, sharing data throughRSS feeds and APIs, and providing Findory content to websites and weblogs with Findory Inline.

Findory’s growth has stalled lately, casting some doubt on the strategy of pursuing word of mouth and viral marketing alone. Again, the question comes up over whether to spend time and treasure on non-traditional or traditional marketing.

The Team

Building a strong team around a startup is important. No doubt about it, I was slow to build a team for Findory.

Findory was started with a very modest amount of capital, probably too small. The on the cheap strategy meant Findory could not pay salaries or benefits. That made hiring and building a team difficult.

I did not want to bring people on part-time who were not dedicated to success of company, but I could not offer what people need — at least a modest salary — to come on full time.

In retrospect, I should have increased the initial capital invested, paid small salaries, and brought more people on the team. I was too concerned about the burn rate and not concerned enough about getting the right people on board quickly.

I also should have brought on advisors and formed an advisory board. The assistance and connections would have been valuable. Worries about loss of independence and dilution of ownership should have taken a back seat to getting the advice I needed.

Finally, I should have brought an angel on the team. As I learned withour lawyers, the advice and network I would have gained from a dedicated angel would have been as valuable as the funding. A modest amount of additional funding also would have been sufficient to pay 1/3 salaries to a couple employees, easing the build out of the critical early team.

It is ironic. I started Findory because I was passionate about an ideaand loved the speed of execution I gained from my independence. In my excitement, I forgot the importance of sharing that passion with others and depending on their advice.

Infrastructure And Scaling

From the beginning of Findory, I was obsessed with performance and scaling.

The problem with personalization is that that it breaks the most common strategy for scaling, caching. When every visitor is seeing a different page, there are much fewer good opportunities to cache.

No longer can you just grab the page you served the last guy and serve it up again. With personalization, every time someone asks for a page, you have to serve it up fresh.

But you can’t just serve up any old content fresh. With personalization, when a visitor asks for a web page, first you need to ask, who is this person and what do they like? Then, you need to ask, what do I have that they might like?

So, when someone comes to your personalized site, you need to load everything you need to know about them, find all the content that that person might like, rank and layout that content, and serve up a pipin’ hot page. All while the customer is waiting.

Findory works hard to do all that quickly, almost always in well under 100ms. Time is money, after all, both in terms of customer satisfaction and the number of servers Findory has to pay for.

The way Findory does this is that it pre-computes as much of the expensive personalization as it can. Much of the task of matching interests to content is moved to an offline batch process. The online task of personalization, the part while the user is waiting, is reduced to a few thousand data lookups.

Even a few thousand database accesses could be prohibitive given the time constraints. However, much of the content and pre-computed data is effectively read-only data. Findory replicates the read-only data out to its webservers, making these thousands of lookups lightning fast local accesses.

Read-write data, such as each reader’s history on Findory, is in MySQL. MyISAM works well for this task since the data is not critical and speed is more important than transaction support.

The read-write user data in MySQL can be partitioned by user id, making the database trivially scalable. The online personalization task scales independently of the number of Findory users. Only the offline batch process faced any issue of scaling as Findory grew, but that batch process can be done in parallel.

In the end, it is blazingly fast. Readers receive fully personalized pages in under 100ms. As they read new articles, the page changes immediately, no delay. It all just works.

Even so, I wonder if I have been too focused on scaling and performance. For example, there have been some features in the crawl, search engine, history, API, and Findory Favorites that were not implemented because of the concern about how they might scale. That may have been foolish.

The architecture, the software, the hardware cluster, these are just tools. They serve a purpose, to help users, and have little value on their own. A company should focus on users first and infrastructure second. Despite the success in the design of the core personalization engine, perhaps I was too focused on keeping performance high and avoiding scaling traps when I should have been giving readers new features they wanted.

Please see also a post on O’Reilly Rader, “Database War Stories #8: Findory and Amazon”.

Hardware Go Boom

Computers go down, a lot more often than we might like.

For most of Findory’s four years, it ran on six servers. In that time, those servers had one drive failure, one bad memory chip, and four power supplies fail.

Of these, only the two power supply failures caused outages on the site, one of one hour and one a painful eight hour outage. There were a few other short outages due to network problems in the data center, typically problems that took the entire data center offline temporarily.

Findory’s six servers were all cheap commodity Linux boxes, typically a single core low-end AMD processors, 1G of RAM, and a single IDE disk. Findory was cheap, cheap, cheap.

The reliability of Findory over its lifetime was perfectly acceptable, even quite good compared to other little startups with similar levels of traffic, but I think it is interesting to think about what may have been able to prevent the outages without considerable expense.

Surprisingly, RAID disks would not have helped much, though they would have made it easier to recover from the one drive failure that did occur on a backend machine. Better redundancy on the network may have helped, but would have been expensive. Splitting servers and replicating across data centers may have helped, but would have been both expensive and complicated for a site of Findory’s size and resources.

Probably the biggest issue was that Findory did not have a hot standby running on its small database. A hot standby database would have avoided both the one hour outage and the eight hour outage. Those outages were caused by losing the first, then a second power supply on the database machine.

Looking back at all of these, I think it was particularly silly not to have the database hot standby. The cost of that would have been minimal and, not only would it have avoided the outage, but it would have reduced the risk of data loss by having a constant database backup. I almost added the hot standby many times, but kept holding off on it. While I may have mostly gotten away with it, it clearly was a mistake.

Other thoughts? Anyone think it was foolish not to run in RAID and not to be split across data centers? Or, maybe you have the opposite opinion, that small startups should not worry much about uptime and small outages are just fine? How about the hardware failure rates, are they typical in your experience?

Funding

I had the wrong strategy with trying to get funding for Findory. I pursued VCs instead of angels.

I should have realized, VCs would never fund Findory. From their point of view, there was just too much risk.

Findory was lead by a first time entrepreneur and was missing critical expertise in building a company. Findory lacked a full team; in particular, there was no finance, marketing, or business development talent. And, Findory had an unproven technology — a specific technique for personalizing news, search, and advertising — that is difficult for a VC firm to evaluate.

Had any one of these three been different, there might have been a better chance. A proven founder may be able to get funding with nothing more than an idea on a napkin. A strong team ready to go is an attractive investment for a VC. A proven technology that just needs the wind of capital behind it is an easy bet. But, with all three missing, there was never much of a chance.

Perhaps in the frothier SF Bay Area, this might have been different. Perhaps someone might have taken a gamble. In Seattle, there are only a half a dozen VCs doing substantial internet investing; most firms out of Seattle will not fund without a local firm joining in the round.

I did pitch dozens of venture capitalists in and outside of Seattle on Findory. It was a fascinating experience, educational, exciting, and often humbling. But, ultimately, I have to say it was a wasteful distraction from building things to help Findory readers.

I should have focused on angels. Not only would angels have brought the right amount of cash for short-term needs, but also the addition of experienced angels to the board would have provided valuable advice and connections. It would have been just what Findory needed.

I had thought that, with how far I had bootstrapped Findory, that I could skip a step and jump directly to VCs. That was foolish. Findory remained a long way from the point where the momentum would be so obvious that it would overwhelm the other concerns.

Instead of looking to VCs, I should have looked for an experienced angel, someone passionate about personalizing information, who would have given the startup the advice it needed while enjoying the experience of joining with us to grow the company.

Please see also Paul Graham’s article, “A Hacker’s Guide to Investors”.

Please see also Paul Graham’s article, “Why There Aren’t More Googles”, especially his discussion of VCs as tending to be surprisingly “conservative” and “driven by consensus”.

Acquisition Talks

At various points when I was running Findory, I approached or was approached by other firms about acquisition. For the most part, these talks went well, but, as with many experiences at Findory, my initial expectations proved naive. It gave me much to contemplate, both for what startups should think about when entering these talks and changes bigger companies might consider in how they do acquisitions.

For a startup, acquisition talks can be a major distraction. It is time away from building features for customers. It creates legal bills that increase burn rate. It distracts the startup with nervous flutters over uncertainty over the future, potential distant payouts, and the complexity of a move.

Acquisition talks also can be dangerous for a startup. Some companies might start due diligence, extract all the information they can, then decided to try to build themselves.

There is some disagreement on this last point. For example, Y-Combinator’s Paul Graham wrote, “What protects little companies from being copied by bigger competitors is … the thousand little things the big company will get wrong if they try.” Paul is claiming that big companies have such poor ability to execute that the danger of telling them everything is low.

However, big companies systematically underestimate the risk of failure and cost of increased time to market. For internal teams, which often already are jealous of the supposedly greener grass of the startup life, the perceived fun of trying to build it themselves means they are unreasonably likely to try to do so. Paul is right that a big company likely will get it wrong when they try, but they also are likely to try, which means the startup got nothing from their talks but a distraction.

There are other things to watch out for in acquisition talks. At big companies, acquisitions of small startups often are channeled into the same slow, bureaucratic process as an acquisition of a 300-person company. Individual incentives at large firms often reward lack of failure more than success, creating a bias toward doing nothing over doing something. In fact, acquiring companies usually feel little sense of urgency until an executive is spooked by an immediate competitive threat, at which point they panic like a wounded beast, suddenly motivated by fear.

Looking back, my biggest surprise was that companies show much less interest than I expected in seeking out very small, early-stage companies to acquire.

As Paul Graham argued in his essay, “Hiring is obsolete”, for the cost of what looks like a large starting bonus, the companies get experience, passion, and proven ability to deliver. By acquiring early, there is only talent and technology. There is no overhead, no markups for financiers, and no investment in building a brand.

Moreover, as the business literature shows, it is the small acquisitions that usually bring value to a company and the large acquisitions that destroy value. On average, companies should prefer doing 100 $2–5M acquisitions over one large $200–500M one, but business development groups at large companies are not set up that way.

There is a missed opportunity here. Bigger companies could treat startups like external R&D, letting those that fail fail at no cost, scooping up the talent that demonstrates ingenuity, passion, and ability to execute. It would be a different way of doing acquisitions, one that looks more like hiring than a merging of equals, but also one that is likely to yield much better results.

For more on that, see also Paul Graham’s essay, “The Future of Web Startups”, especially his third point under the header “New Attitudes to Acquisition”.

Starting Findory Series: The End was originally published in 10,000 Ways to Fail on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Steve Poland

I’m officially putting MyFavorites behind me. The problem I was trying to solve, isn’t one of those problems you think you have… and I think those types of solutions/startups are a bit tougher. I already outlined my own problems with running a startup in a prior post about MyFavorites (“Repeat after me, I will not do another startup as a non-technical founder unless…“).

I’m writing this post with the intentions of telling you about the idea, sharing the debates that occurred with how the app should operate and be used, share mockups with you, share documents/spreadsheets of tasks/bugs/features/timelines, and simply give a glimpse into this failure. It was a failure because I called quits on it — I ultimately couldn’t keep funding it myself and the team was losing interest in working on this app that I kept going back-and-forth on how the user experience should play out — when we hadn’t even had any users using it yet.

THE IDEA

My initial pitch for MyFavorites was “Show + Tell Your Favorites”. That pitch eventually became: “The Like button for everything.” Nick came up with that one and it was solid gold — would have made a great TechCrunch post title… we discussed possibly using it as our tagline, knowing it might be controversial and Facebook might sue — but any press is good press

We weren’t going to do that though. [Quick shout-out to Buffalo-native Chris Sacca, whose portfolio list has a one-liner that sums up every single company. If you can’t do that for your startup, then you’re likely too broad and not simple enough. Remember, if you can’t explain your solution to your Mom so she can understand it, then most people won’t understand it and they especially can’t explain it to their friends]

The problem we tried to solve — wouldn’t it be great to know the favorite books of your friends (and celebs), so you know what book you should be buying to read this weekend? Facebook has interests, but have you ever updated those since you signed up for Facebook? Wouldn’t it be great to know your friend’s favorite … anythings? You’d be looking at a feed of just favorites — blog posts, beers, sneakers, drinks at Starbucks, things to do in Baltimore, apps for iPhone, tree cutting services locally, meals at a restaurant, etc.

Wouldn’t it be cool to see all of Ashton’s favorites? Or Britney Spears, or any celebrity?

We were tackling the “interest graph”. You can find lots of my notes and findings at the MyFavorites blog.

I’ll tell you my grandiose billion-dollar idea for MyFavorites — imagine 50k people that took pictures of themselves with their love for Starbucks (or any brand). Sure, Starbucks currently can show a Facebook widget that shows profile pics of their Facebook fans… but imagine just replacing their homepage with 50,000 people showing their absolute love for Starbucks? That’d be amazing — Starbucks doesn’t even need to say anything about their products, because here’s people that vouch for us. Imagine Gary Vaynerchuk when selling his next book to just show tons of pictures of people with his last book, showing creatively how much they love garyvee?

With all of these pictures, a new ad network could be created — per the one I wrote about back in 2007 (“Ads with Personal Endorsements“) — this is the future, there’s no doubt about that. The problem is how do you get people to take pics of themselves with brands/products that they absolutely love and personally vouch for?

In the feed, our plan was to always have a #dickbar at the top of the screen. That would be asking the user for their favorites. At first, these would all be some default categories that we ask everyone, but as the user gets friends and follows people, anytime those users are asking people for favorites in a category, that user’s profile pic and name would show in the #dickbar with category they want favorites for. Meanwhile, there’d be sponsored favorite questions — such as, if you favorited Doritos, then Doritos could ask you “What’s your favorite Doritos flavor?”, or if you favorited Starbucks, it could be asked “What’s your favorite drink at Starbucks?”, etc. It just keeps going and going. [Here’s a spreadsheet of some more sub-question examples]

As a user favorites something, there would be sub-questions to those categories. If you favorited ‘NFL’, then we could ask the question, “What’s your favorite NFL team?”. The plan was to allow multiple favorites for any category, for every user… so that everytime you were drinking a beer you loved, we wanted you to whip out your phone and favorite it. Then you’d have a ranking of your favorite beers — with # of times you favorited each one. You’d also be able to see the favorite beer tally of all your friends combined, or individually… so then you would know the most popular beer amongst your friends. With us knowing where you live and where you’re favoriting this stuff, we could also figure out the most popular ANYTHING in every city — that’s powerful. We could basically show a map of the world and show Gibson vs Fender and which guitar brand is the leader in every city, every state, and every country.

LOGO

I used 99designs. I know that basically every designer out there loathes this service and anyone that uses it, but I beg to differ. If you’re awesome, you aren’t going to be replaced by 99designs. I think it’s a great opportunity for college kids and international designers that don’t have access to design work. It’s a great platform for learning as a designer — understanding a client’s needs/requirements/vision and trying to design for that. The designer gets feedback from not only the client, but other designers — and can see feedback on other designer’s work by the client [and others]. As a designer you need to go into knowing you’re basically paying for education — you pay by doing work for free and likely not going to get paid for that work. You go to school and pay for that education. Education and experience costs money and time. 99designs is disruptive and I understand the controversy. Various designers in the world will continue using it and so will various people — but it’s not going to become the defacto for the entire design world.

With the MyFavorites logo, I wanted something that could eventually be placed on blog posts like the Twitter ‘tweet’ button and the Facebook ‘like’ button.

FAVORITING PROCESS

We went back and forth on this so many times I can’t count them all. Granted, I was the one changing my mind a lot. We initially started with a sentence strategy — you would say “My Favorite beer is Duvel” — so basically “My Favorite (category) is (item)”. The problem you run into is pluralization — is vs are. I can’t even speak to all the issues with this, but our language is a mess

[Here’s a screenshot of an old sentence structure process for our app]

The other problem with the sentence structure is that it seems a bit lengthy. We all went to SXSW 2011 and were almost ready to launch the app (this was after weeks of tons of late nights trying to cram this app to be ready) … and then we all saw Pete Cashmore’s interview of Dennis Crowley … where Dens talks about making the checkin process as easy as possible.. and I realized we needed to simplify our favoriting process. Nick had mentioned many weeks prior that we should start the process by showing like 10 default categories, with the ability for user to choose ‘other’ and input their own category. This would help guide our users and make the process slicker. So that was our final strategy on this focal UX point of the app.

We also originally allowed the user to input multiple categories for a favorite — this seemed to like it would make the user have to “think” too much. We found ourselves wondering what categories/tags to use.

Our other strategy was to focus on the ability for users to add tips to Foursquare. Initially we thought that when someone favorites something, they’d be able to checkin at Foursquare, post it to Twitter and Facebook. That doesn’t really make sense though — I use the Foursquare app — I opened that as soon as I walk into a venue — that’s when I think to use that app. The idea with MyFavorites is to use it when you are loving something — so likely, you’re already checked-into a Foursquare venue, and so this would be an ability to add more tips into Foursquare…. which hasn’t been done yet. No other apps are focused on getting more tips into Foursquare — and to me, tips are the most valuable aspect of Foursquare.

The big problem we just never knew how to answer until the app started getting used, was we didn’t know what to give the user after they favorited something. Foursquare gives points, random badges… should MyFavorites being doing game mechanics like this? Leaderboard seemed pertinent to us — but specifically showing the user what other favorites exist in the category they just favorited in — and where their current favorite item ranks in relation to other items they have favorited in that same category (i.e. ‘Pabst Blue Ribbon is your 3rd favorite beer!’). [Here’s an old leaderboard mockup and another one specific to a user] [Here’s a spreadsheet of tons of possible messages we could have delivered to the user after they favorited something]

MOBILE APP vs WEB APP

Initially we were building both an iPhone & Android app (after establishing our dev platform as Titanium Appcelerator), as well as a website where you could favorite things as well. It was all too much. Even with Titanium’s ability to “write once, and push out an iPhone and Android app” — that’s false; it takes a lot of work to manipulate features for iPhone and Android — there’s no scroll wheel function in Android; there’s no menu button on iPhone as there is on Android.

Having a web app being created at the same time was ridiculous too — especially since we still hadn’t nailed down the favoriting process or tried it with any users. I was blowing cash — at a ridiculous pace. I had 7 guys working on this thing at once, as we were hustling for SXSW launch deadline. We decided to focus on the iPhone app, which sucked for me and Dan the backend programmer, because we both couldn’t even use the app — we both have Droid X phones.

Focus on one platform. Get it out there — let people use it — nail down the UX with user input.

SOCIAL INTERACTIONS

I looked at Twitter, Facebook and Foursquare — then wrote a post called the “Metrics of me, me, me!” — basically the conscious and subconscious interactions/metrics we make with these services. I also blogged about the “usage psychology” of those services to better understand how we could hook MyFavorites users. Our social interactions were the following:

• favorite [default action; like a tweet or checkin]
• ‘me too’ [trying to get users to add more favorites easier]
• ‘reply’ [ability for users to reply to someone’s favorite with their own favorite — i.e. your favorite car is a Nissan Altima, well mine is a Mattel. We found a lot of humor came from this action]
• ask for favorites [ability for user to ask friends for their favorites in a category — i.e. if I were going to Ireland for vacation, what are things to do there?] [users would simply ‘reply’ with their favorite]

API

Eventually we wanted to open an API that allowed you to have favorites auto-imported — such as Twitter favorites, who uses that feature on Twitter anyway? Our site would give you a reason to use favoriting on Twitter. For YouTube, we’d auto-import stuff you favorite in there. Lots of apps out there have a like or favorite ability, and it seems like an opportunity exists for aggregating all of that.

MOCKUPS OF FUNCTIONALITY

These obviously took tons of hours of our lives nailing these. We looked at lots of apps for help/ideas.

Question Process:

This was up for serious debate all the time. Basically, I wanted this. I wanted to be able to ask my friends what their favorite things to do in Ireland were. Or Hawaii, where I’m going for my honeymoon. Or I am looking for someone to take down this tree in my backyard — Yelp sucks in Buffalo, so how can I find a friend that can recommend a tree cutting service? So the ‘where’ was a big issue — I didn’t want just a ‘tree cutting service’, I wanted a ‘tree cutting service in Buffalo, NY, USA’. So we had this ‘Where?’ optional field, which then would either take a Foursquare venue, or you could select a city or country from a DB we had. It was a complete mess — it was confusing to users [especially when we had this on the Favoriting process] — and the rest of my team didn’t think we needed this functionality at all anyhow.

Profile Settings and Adding Friends:

Signup:

Favorite page on web — we ultimately decided to do the Instagram thing, which was have a non-interactive website initially and simply have a webpage for every favorite that occurs by users, so that these could be shared. I think this minimal design was great and we planned to build out feed/category/profile pages on the web this way too:

Search / Discovery — nearby and everywhere. By the people you follow, or everyone. Too many options and thus too cluttered IMO:

Documents / Spreadsheets

• Sharing to Facebook and Twitter and Foursquare — get new users! Here’s a spreadsheet of all the possible copy (tweets, etc) that could have been used.
• URL examples of our website as a spreadsheet (more ideas of our future plans).
• Here is a spreadsheet of our final team push towards a launch. These were the remaining features to finish and some hours estimates on completing them.
• Here is a monster feature / task list, which clearly was just out of control. I didn’t know how to tame my beastly instincts for “we could do this, and this, and this, and..”
• Here is a list of common categories that most people would likely add favorites for.
• Here is a monster list of bugs and features (different from above) — you’ll see more ideas of our plans here.

OINK

Meanwhile at SXSW is when I first learned that Kevin Rose was gathering some troops (including Daniel Burka, whose design work I have been following for years in awe) to create Milk Inc., which was going to be an incubator of app ideas. One of those app ideas that possibly was going to be their focus (OINK), was dabbling in similar territory of MyFavorites. We had about 6 months on them, but still — that’s some competition.

THE END

I still want to use an app like MyFavorites — and I hope OINK can nail it. Ultimately, I wasn’t the guy to push this idea through. Being a non-technical founder, I just can’t throw money at this thing in the hopes of nailing it. I believe we were definitely at a point where we could have raised some funding around SXSW timeframe — we had the team, the focus, and an app that was working … but ultimately when we came back from SXSW, we all started losing interest, the team was all wondering where this was eventually going, and I was wondering if I even wanted to run a startup, have investors, have the responsibility of employees and answering to a board of investors, etc.

Moving forward I’m looking to help the OINK guys or anyone working on this problem in any way I can. There’s a solid 6 months of problems, solutions, strategy, userflow, monetization, and everything else under the sun… that went down. And there’s still a massive opportunity out there to nail.

The little startup that couldn’t (a postmortem of MyFavorites) was originally published in 10,000 Ways to Fail on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Justin Kan

Many new online-to-offline entrepreneurs have asked me about my experience founding Exec. “Uber for X” businesses seem to be the startup of the day — it probably helps that on the face they are less technically complex and more accessible to aspiring less-technical founders.

Exec (subsequently changed to “Exec Errands”) started off as us trying to fill my own personal desire for a part-time personal assistant / errand runner. I had enough random tasks that I wanted done and was willing to pay for, but didn’t have enough to pay someone full time. I tried hiring a shared assistant, but it was hard to get her to run same day errands on late notice. I tried Taskrabbit and Craigslist, but the bidding and selection process was too high friction to use for smaller, every day tasks. Eventually, we came up with the first version of Exec, which we described as “Uber meets Taskrabbit”, where anyone from the web or their iPhone could call an assistant who would immediately start running their errand.

On the backend, we had recruited a bunch of people looking for extra work to install our worker app and wait around for jobs. When someone put a job into the system, it would be offered to each errand runner in turn based on their proximity. When a job was accepted, the errand runner would get in touch with the customer, and start running the job. Early customers put in a wide variety of jobs, including dog walking, grocery pickups, temporary office work, and more.

Eventually, we dropped Exec Errands and turned Exec into a pure book-online house cleaning business, which was acquired by Handybook in January. Here are some of the lessons I learned in the early days of Exec Errands about online-to-offline businesses:

Unit economics matter a lot more than in pure software businesses. With Justin.tv, when we wanted to generate more revenue, we would look hard and figure out yet undiscovered places to shove another ad unit. Actual COGs (bandwidth and servers) were only ~30% of our gross revenue — most of our expenses were software engineers working on improving the product. With Exec Errands, we paid out 80% of the $25 / hour that we billed for errand runner time on job. That means that all marginal customer acquisition, customer service, and recruiting sufficient supply of errand runners had to be paid for out of that remaining 20%. Paying for mistakes (workers messing up a job) or customer refunds quickly ate up any profits.

Turnover of errand runners was very high. Most competent people are not looking for part-time work. The exception to this are people looking for supplemental income, but those people have full time jobs which conflicted with our high demand periods: mid-morning of the work week, Monday — Friday. Hiring new errand runners was expensive, and it was difficult to get them to stick around when we couldn’t guarantee work — the average utilization (time on the job / time available) was only 50%. Additionally, most of our errand workers wanted to work during normal work days, meaning there was an undersupply on weekends.

Demand was very spiky. It turns out that $20 / hour does not provide enough economic incentive in San Francisco to dictate when our errand runners had to be available, leading to large supply gaps at times of spiky demand. Without some form of Uber-like surge pricing, it was impossible to ensure that we had consistent availability.

Customer acquisition was hard. Lyft and Uber are viral online-to-offline businesses, because many of the times you call a ride you take it with others (who subsequently think it’s an incredible experience and download the app). Exec Errands was a not nearly as viral (and cleaning not at all), because you could use those services without ever telling anyone.

Customer activation was hard. Only about 10% of people who signed up for Exec Errands activated (put in at least one job request). When they heard about Exec, people thought it sounded like a cool idea, but rarely did they have an errand waiting in their back pocket that they hadn’t yet run — making it hard for them to try us immediately. This led to reduced activation rates and high customer acquisition costs (since fewer signups turned into actual customers).

We shouldn’t have run jobs ourselves. In the early days, if a job request came in and there were no Execs available to run them (as was often the case due to spiky demand), we sent someone from the office to run the jobs ourselves. We called that eating our own dog food and giving ourselves a sense of what could be improved about the product for both errand runners and customers. Unfortunately, this gave us a false sense that the quality of service for our customers was better than it was, as the average competence of our employees was higher than our average recruitable errand runners.

Verticalize. Ironically, Exec was very similar to Justin.tv in this way: the product got a lot better when we started focusing on a specific vertical, and surprisingly, grew much faster. With Justin.tv, we discovered that a small number of users were very passionate about gaming, and thus we started working on Twitch, a community based around watching gaming video, which seemed like a very small niche to us at first. Now, Twitch has 45 million monthly viewers, and is many times the size of Justin.tv. I failed to learn the lesson the first time around, and started Exec Errands as a general errand running site that you could put any job into, from shopping to cleaning to getting your car washed. When you do many things, it is hard to do any one thing well, and Exec Errands turned out to be a merely adequate tool for many jobs, but not an exceptional one. When we started focusing only on cleaning, we were able to vet workers against a smaller skill set, provide specific tools, and streamline the interface to make purchasing more intuitive and simpler (and thus increase conversions), resulting in much better growth.

As a programmer entrepreneur whose previous businesses were purely online, those are some of the things I wished I had known when first starting work on Exec Errands. Hopefully this is useful for you.

What I learned about online-to-offline was originally published in 10,000 Ways to Fail on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Mark Hendrickson

Nearly three years ago, I left my position at TechCrunch to start my own Internet business, with the idea of creating a web application that’d help people get together in real-life rather than simply helping them connect online as most social networking applications had done.

Plancast was the service conceived a few months later from that basic inclination. Its approach was to provide a really easy way for people to take whatever interesting plans they had in their calendars and share them openly with friends, with the rationale that greater social transparency for this particular type of personal information would facilitate serendipitous get-togethers and enable a greater awareness of relevant events. Personally, I figured that knowing more about the events my friends and peers were attending would lead to a more fulfilling social and professional life because I could join them or at least learn about how they spent their time around town.

Along the way my team built a minimum viable product, launched from obscurity here on TechCrunch, raised a seed round of funding from local venture capitalists and angel investors, and worked like mad to translate our initial success into long-term growth, engagement and monetization.

Alas, our efforts began to stall after several months post-launch, and we were never able to scale beyond a small early adopter community and into critical, mainstream usage. While the initial launch and traction proved extremely exciting, it misled us into believing there was a larger market ready to adopt our product. Over the subsequent year and a half, we struggled to refine the product’s purpose and bolster its central value proposition with better functionality and design, but we were ultimately unable to make it work (with user registration growth and engagement being our two main high-level metrics).

This post-mortem is an attempt to describe the fundamental flaws in our product model and, in particular, the difficulties presented by events as a content type. It’s my hope that other product designers can learn a thing or two from our experience, especially if they are designing services that rely on user-generated content. The challenges I describe here apply directly to events, but they can be used collectively as a case study to advance one’s thinking about other content types as well, since all types demand serious analysis along these lines should one seek to design a network that facilitates their exchange.

Sharing Frequency

Social networks (by my general definition and among which I count Plancast) are essentially systems for distributing content among people who care about each other, and the frequency at which its users can share that content on a particular network is critical to how much value it’ll provide them on an ongoing basis.

Unlike other, more frequent content types such as status updates and photos (which can be shared numerous times per day), plans are suitable for only occasional sharing. Most people simply don’t go to that many events, and of those they do attend, many are not anticipated with a high degree of certainty. As a result, users don’t tend to develop a strong daily or weekly habit of contributing content. And the content that does accrue through spontaneous submissions and aggregation from other services is too small to provide most users with a repeatedly compelling experience discovering events.

I run the service, and even I currently have only five upcoming plans listed on my profile, with a total of 500 plans shared over the last couple of years, in contrast to almost 2,800 tweets on Twitter over the same period of time. People often tell me “I like Plancast, but I never have any plans to share”. With social networks, this is sometimes a case of self-awareness (such as when people say they don’t know what to tweet), but often they’re simply telling the truth; many Plancast users don’t have any interesting plans on their calendars.

Consumption Frequency

People also don’t proactively seek out events to attend as you might suppose. I’ve gotten into the habit of thinking about people as divided into two camps: those who have lots of free time and those who don’t.

Those who do are often proactive about filling it, in part by seeking out interesting events to attend in advance. They are generally more inquisitive about social opportunities, and they will take concrete steps to discover new opportunities and evaluate them.

Those who don’t have much free time often desire to conserve it, so rather than seeking out or welcoming additional opportunities, they view them as mentally taxing impositions on a limited resource. For them, planning is a higher-risk endeavor, and usually they’d rather not plan anything at all, since if they’re busy, they likely have a preference to keep their free time just that — free.

It’s hard to generalize by saying most people are in one camp or the other, but suffice to say, there are many people in the latter. And for them, it’s hard to get them excited about a service that will give them more options on how to use their time.

Tendency to Procrastinate

Even putting this bifurcation aside, most people resist making advanced commitments before they absolutely need to make them. People fear missing out on worthwhile events but don’t actually like to take the deliberate initiative to avoid such missed chances, which requires planning.

This can be attributed primarily to people’s desire to keep their options open in case other conflicting opportunities emerge as the date and time of an event approaches. If they can afford to wait and see, they will. Therefore, their commitment will be secured and shared in advance only when they’re particularly confident they’ll attend an event, if they need to reserve a spot before it fills up, or if there’s some other similar prerogative.

Incentives to Share

Returning to the topic of sharing plans, it’s not only a matter of having interesting plans to share but being compelled to actually share them. And unfortunately, people don’t submit information to social networks because they love data set integrity or altruistically believe in giving as much as possible. They do it because the act of contribution selfishly results in something for them in return.

Most social networks feed primarily on vanity, in that they allow people to share and tailor online content that makes them look good. They can help people communicate to others that they’ve attended impressive schools, built amazing careers, attended cool parties, dated attractive people, thought deep thoughts, or reared cute kids. The top-level goal for most people is to convince others they are the individuals they want to be, whether that includes being happy, attractive, smart, fun or anything else.

This vanity compels folks to share content about themselves (or things they’ve encountered) most strongly when there’s an audience ready and able to generate validating feedback. When you post a clever photo on Instagram, you’re telling the world “I’m creative!” and sharing evidence to boot. Those who follow you validate that expression by liking the photo and commenting positively about it. The psychological rush of first posting the photo and then receiving positive feedback drives you to post more photos in the hope of subsequent highs.

Sharing plans, unfortunately, doesn’t present the same opportunity to show off and incur the same subsequent happy feelings. Some plans are suitable for widespread consumption and can make a person look good, such as attending an awesome concert or savvy conference. But, frustratingly, the vainest events are exclusive and not appropriate for sharing with others, especially in detail.

The feedback mechanisms aren’t nearly as potent either, since coming up with a worthy comment for an event is harder than commenting on a photo, and “liking” a plan is confusing when there’s also an option to join. The positive feedback of having friends join is itself unlikely since those friends have considerations to make before they can commit, and they’ll tend to defer that commitment for practical purposes, per above.

Additionally, if a user wants to show off the fact they’re at a cool event, there is little additional benefit to doing so before the event rather than simply tweeting or posting photos about it while at the event. An important exception is to be made for professionals who style themselves as influencers and want to be instrumental parts of how their peers discover events. This exception has indeed been responsible for much of our attendee-contributed event data among an early-adopter community of technology professionals.

Selectivity & Privacy Concerns

Vanity, of course, is not the only possible incentive for users to share their plans. There’s also utility to getting others to join you for an event you’ll be attending, but this turns out to be a weak incentive for broadcasting since most people prefer to be rather picky about who they solicit to join them for real-life encounters.

While event promoters have a financial interest in attracting attendees far and wide, the attendees themselves mainly turn to their closer circle of friends and reach out to them individually. You don’t see a lot of longer-tail plans in particular (such as nights out on the town and trips) because people are both wary of party crashers and usually uninterested in sourcing participants from a wide network.

The Importance of an Invitation

On the flip-side of this reluctance to share plans far and wide is the psychological need for people to get personally invited to events.

Plancast and other social event sharing applications are rooted in an idealistic notion that people would feel confident inviting themselves to their friends’ events if only they knew about them. But the informational need here is not only one of event details (such as what’s going to happen, when, where and with whom). People often also need to know through a personal invitation that at least one friend wants them to join.

When you have a service that helps spread personal event information but doesn’t concurrently satisfy that need, you have a situation where many people feel awkwardly aware of events to which they don’t feel welcome. As a result, the most engaging events on Plancast are those that are open in principle and don’t solicit attendees primarily through invitations, such as conferences and concerts, where the attendance of one’s friends and peers is a much less important consideration for their own.

Content Lifespan

Getting content into a social network is not enough to ensure its adequate value; there’s also an importance of preserving that content’s value over time, especially if it just trickles in.

Unfortunately, plans don’t have a long shelf life. Before an event transpires, a user’s plan for it provides social value by notifying others of the opportunity. But afterwards, its value to the network drops precipitously to virtually nothing. And since most users don’t have enough confidence to share most plans more than one or two weeks in advance, plans are typically rendered useless after that length of time.

Contrast this expiration tendency with more “evergreen” content types, such as profiles and photos. Other people can get value out of your Facebook profile for years after you set it up, and the photos you posted in college appear to have even increased in value. Nostalgia doesn’t even have to play a part; people’s hearts will melt upon viewing this puppy on Pinterest, Tumblr, and other visually-heavy content networks for a long time to come. But how much do you care that I attended a tech meetup in New York last October, even if you’re my friend?

Geographic Limitations

Geographic specificity is another inherent limitation to a plan’s value. Unlike virtually all other content types (with the exception of check-ins), plans provide most of their value to others when those users live or can travel near enough to join.

I may share plans for a ton of great events in San Francisco, but few to none of my friends who live outside of the Bay Area are going to care. In fact, they’ll find it annoying to witness something they’ll miss out on. Sure, they might appreciate simply knowing what I’m up to, but the value to that kind of surveillance is rather modest all by itself.

This is especially problematic when trying to expand the service into new locations. New users will have a hard time finding enough local friends who are either on the service and sharing their plans already, or those who are willing to join them on a new service upon invitation. People who encounter the service from non-urban locations have the hardest time, since there aren’t many events going on in their area in general, let alone posted to Plancast. Trying to view all events simply listed within their location or categories of interest yields little for them to enjoy.

Looking Forward

Despite all of these challenges, I still believe someone will eventually figure out how to make and market a viable service that fulfills our aims, namely to help people share and discover events more socially. There’s simply too much unearthed value to knowing about much of what our friends plan to do to leave information about it so restricted to personal calendars and individuals’ heads.

Another startup may come along that develops insight into an angle of attack we missed. Or, perhaps more likely, an established company with an existing event or calendaring product will progressively provide users with a greater ability to share their personal information contained within. On the calendaring side, Google is possibly the best-situated with Google Calendar and Google+, which together could make for a very seamless event sharing experience (one of the things we considered seriously for Plancast was deep personal calendar integration, but a sufficient platform for it simply wasn’t available). On the events side, companies like Eventbrite, Meetup and Facebook have services that are primarily compelling for event organizers but already contain useful data sets that could be leveraged to create their own social event discovery and sharing experiences for attendees.

Plancast managed to attract a niche audience of early adopters who found it to be among the most efficient ways to share and hear about events (thanks, users! you know who you are). Over 100,000 have registered and over 230,000 people visit each month, not to mention enjoy the event digests we send out by email each day. For that reason alone, and despite its growth challenges, we’re going to keep it up and running for as long as possible and are hopeful we’ll find it a home that can turn it into something bigger. It’s my expectation that one day mainstream society will take for granted the type of interpersonal sharing it currently enables for just this small community, and I look forward to seeing how technological advancements overcome the aforementioned challenges to get us there.

The Uphill Battle Of Social Event Sharing: A Post-Mortem for Plancast was originally published in 10,000 Ways to Fail on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Gary Swart

My former company, Intellibank, was sort of like Dropbox done wrong. You’ve probably never heard of Intellibank, because it came and went like so many startups do, but it was a promising company with smart people. We raised money and could have been the next big thing, but it never happened. Why?

Though Intellibank was not successful, I don’t view my time there as wasted. From the mistakes we made, I learned what not to do — and from there, I’ve arrived at some essential truths that can lead to startup success.

1. It’s all about the market

Even the best team with the best product will fail if its market does not exist. Venture capitalist Marc Andreessen says that product-market fit (a term he is said to have coined) is one of the most important factors he considers when evaluating startups.

At Intellibank, we did not achieve product-market fit. Every customer was asking for something different and we gave it to them. We had six markets with 40 different types of customers, and in hindsight, we should have developed just one product. We couldn’t be all things to all people — and by failing to declare our major, we created a world of chaos for our sales, product and marketing teams.

Even if you do have product-market fit, you will not get very far if the market is not big enough. To determine whether you fall into that category, ask yourself if the market you’re targeting is big enough to allow for pervasive adoption of your product and exponential growth.

2. Validate with your customers, not your investors

A common mistake among entrepreneurs is seeking validation of their ideas and decisions from investors. The most important people any company should seek validation from are their customers. That’s right, your customers matter more than your investors — and any good investor would agree.

Do not ignore yellow lights coming from your early adopters, because their activity indicates a momentum shift. Spend time understanding all aspects of the customer value proposition. I once heard Guy Kawasaki talk about his 10X rule — in order for people to switch and buy your new thing, your product doesn’t need to be perfect, it just needs to be 10X better than the alternative. Think about the 10X rule and ask yourself: why should your customer buy your product? How does your product fit into the rest of his world? What influences their opinion of the product’s value? What is your product displacing — all products displace something — and why should your customer risk making that switch? You need to be as knowledgeable about your customer and their needs as you are conversant with your own product.

3. Focus, focus, focus

Focus and simplicity are often more difficult to achieve than building features on top of features on top of features. As a result, too many startups are unfocused. The time required to trim back an idea is not insignificant — said best by Mark Twain: “If I had more time, I would have written a shorter letter.”

In order to succeed, a startup needs to do one or two things exceptionally well; some of the greatest products today don’t have a million bells and whistles, but they solve one concrete problem brilliantly. I’m thinking of companies like Salesforce.com in the early days. They entered the market with good products, and over time they iterated, grew and added features — but not before they owned essentially the entire market.

By keeping it simple, measurable and achievable you’ll be well on your way. Everyone at your company should be able to articulate the goal of your business, enabling a dogged, unyielding focus on that goal throughout the organization.

4. Aim to exceed expectations

Your goal should not be meeting your customers’ expectations; it should be exceeding them. Truly great and memorable products surprise and delight their customers, so don’t be afraid to spend the time and money to build an exceptional product. But don’t let this pursuit inflate your product’s ego, if you will — making promises you cannot keep will leave you surrounded by disappointed customers, investors and employees.

I cannot emphasize how important it is in the long run to over-deliver to your customers. For example, Fab does not have to give every customer a $5 gift card with every order, but doing so wins them a lot of brand loyalty and even word-of-mouth marketing.

5. Figure out streamlined metrics to measure your progress

I once had a board member tell me that we were over-measured and under-prioritized. It stung. A lot. But it also made quite an impression. As a business leader you need to figure out the metric that matters most for your company and understand that the more you measure, the less prioritized you’ll be. Don’t fall into the trap of trying to measure everything. What I’ve learned is that in the early days, what matters most is having customers who love and use your product. Figure out the one or two best measures to determine this.

6. Pivoting is okay… but it is not a business strategy

I learned this one the hard way. At Intellibank, we would change our pitch deck based on what we thought would get us traction with investors. In one particular meeting, I was in the middle of explaining our revenue model, when a potential investor interrupted me and asked, “Can you tell me what your product actually does?” We were pivoting so often for different types of customers that we completely lost the big picture. You must be agile, but not to the point of an identity crisis; you have to look beyond your four walls and convey the big picture.

7. Ultimately, deliver a great experience. It’s what keeps people coming back

Customers come to restaurants for a great overall dining experience, but the food is the baseline. They come back if the service and experience exceed their expectations. It’s the same with any business — the product is table stakes and it’s the experience that brings people back.

Take a look at Hotel Tonight. It’s only accessible from a mobile phone and while there have been several times mid-flight when I’ve wanted to use the app to book my hotel in my destination city, I can’t and so I wait until landing. Using their service on my laptop would be nice, but the experience is so elegant and over-delivers every time, so I prefer to book my hotels there.

With all of these learnings in mind, think about the product you’re selling and think about where you see it going. Now take a step back and ask yourself the most important question of all — when your customers are using the product how do they feel, and will that feeling keep them coming back?

If you liked this post, please share it and click the FOLLOW button above to get more!

Gary Swart is the CEO of oDesk, the world’s largest online workplace.

7 Things I Learned from Startup Failure was originally published in 10,000 Ways to Fail on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Sergio Schuler

Two years ago, on December 2011, I was generating ideas for a business that would help team managers to not suck so much at managing their teams. I came up with this idea because I had some pretty terrible managers in my life. At the same time I worked for about 5 years with leadership development and had some pretty great teams and team experiences. Exactly January 1st 2012 I registered the domain teamometer.com.

Validating the MVP

I was reading The Lean Startup at that time, which is a great book, but not completely fool proof (here is a fool who got it wrong). I started well: in December I created a very basic idea and rough screens of my team management web tool. In January I built a very basic 2 page website with a video explaining what Teamometer.com did and a “try it free” button, which then lead to a page for inputting the email address to capture leads (since I had no product, that was just a test to see if there was demand). Then I bought a few dollars in Adwords to drive traffic to it.

What was good: create a simple and fast website was sweet. The presentation video was pretty good too in my opinion. The Adwords was good to drive traffic too and got a fair share of people who gave me their email address (about 10% of people who clicked the ad).

What could be even better: “try it free” and free trials in general are good if you know your product rocks and you will convert the customer. However, when you are testing demand, it is not the best, because it invites people that are only curious, not really thinking of buying. So the best approach would be to put a price page, see who would click that and after capturing the email telling that the product is not ready and they won’t be charged anything just yet. I would probably get fewer prospects, but the people who did subscribe would be serious about the product.

Where it went wrong: I had all those people who were interested in the product. I judged the product “validated” (WRONG! WRONG! WRONG!) and went on to build it. Looking back, I cannot believe how stupid I was. I had all those people who said they were interested and the obvious next step was NOT building the product, but TALKING to the people who were interested. Asking them things like:

• What were you looking for in Google when you found Teamometer? Why were you looking for it?
• Why is it a problem for you/company?
• How are you trying to solve this problem today?

After discovering their needs, going through with them on what is your idea, to get feedback if you are on the right track.

If I did this, I would have a much better perspective of what people wanted.

Where it went REALLY wrong: one of the prospects was an HR person from a huge Indian manufacturer. They wanted the system NOW and wanted to speak to me. I had a Skype call with them and what they wanted was clearly not what I was thinking to provide with Teamometer. Instead of surfing the wave and adapting my idea to what a real prospect client was telling me they wanted, I entered “sales mode” and sold them my idea, what it would be, how good it was. How dumb is that? I just needed to build what they wanted.

The worst part is that I was blind, thinking that this call had validated my product even more, when in fact it was clearly invalidating it.

Finding partners to build the idea

Once I believed the idea was validated (it was not), I started to scramble to find a way to make the product. I spoke with tons of developers, but my persuasion skills were not impressive enough. I got none. Then an old friend, which founded a million startups, told me he was interested and he knew a guy who was a developer.

Things moved pretty fast, and in no time we were 4 partners: me, the developer, my old friend (background in finance and marketing) and the brother of the developer (background in marketing). And when I say pretty fast, the whole thing literally happened over a cup of coffee, the first time I met the 2 brothers. I needed a developer, I ended up with a developer and 2 business guys. BUT the 2 business guys were also responsible for financing the project.

There are so many lessons to be learned from this and so many stupid mistakes.

Founder roles and expectations. Conflict and disagreement arrived early, because expectations of work and founder roles were not agreed upon and everyone had a different idea about their share of the load:

• The developer had no intention of being the project’s developer (?) he was not really a developer, he was a computer science graduate who owned a webdev shop and was used to managing, not coding.
• Everyone but me had other businesses, so time was constantly an issue and deliverables just didn’t happen timely (which is pretty essential for a fast moving startup).
• Since we were 3 business people, we spent all this time into idiot plans, budget forecasts, BUSINESS CARDS, fancy website… all useless things which in the end did not contribute to anything.

The result of this was that in the end we had to hire a full-time (and paid) developer. So we had zero revenue, 4 co-founders and a paid employee (which was effectively the only one doing real work).

Must I tell you that this was a disaster?

The first partner left the company a few months in. The 2nd one year after. And finally we ended our run after 2 years of zero paying customers.

Learning: I believe a company is the closest to marriage with kids among parents who (probably) don’t have sex or have any sort of romantic love for each other. If marriage with sex and love is already tough, imagine now without any of those things. I should have been much more careful with who to bring in the company. And, if I was convinced of their value, I should have agreed really really well what was expected from each partner.

Never underestimate expectations.

By this time what is really import to hammer through your head is that building the product at this point was a mistake (it was not validated, we needed to speak to prospects). But I made more mistakes which are meaningful:

Finding a painful problem

Literally 100% of the feedback I got from free trial users was that Teamometer was useful and it helped them discover the issues in their team and tackle them. That was exactly what the tool should do, great! So what is the explanation for exactly 0% conversion rate from free trial to paid customers? Why were we not able to sell it?

Simply put, because we didn’t have a painful enough problem.

If a company stops invoicing, they will immediately feel the pain. If a company stops managing well their teams, it can take as much as 1 year for people to realize there is something wrong — and they won’t know what is wrong. Maybe some people will leave, but it is easy to put the blame on the employee or the market.

It is possible to sell soda in the desert (nice to have), but it is much easier to sell water (must have).

(Don’t) multiply big numbers

Multiply $30 times 1.000 clients times 24 months. WOW, we will be rich!

Oh, silly you, you have no idea how hard it is to get 1.000 clients paying anything monthly for 24 months. Here is my advice: get your first client. Then get your first 10. Then get more and more.

Until you have your first 10 clients, you have proved nothing, only that you can multiply numbers.

Forget business cards

…and all the crap about registering company, etc etc etc. While you have no sales (product validation), you should not invest in such gimmicks that only distract from the main goal, which is to find a repeatable business model.

SEO and social media bullshit

Related to the above: I wrote a damn article every effing day. It made us jump to the first page of Google in several important keywords. How did that translate to sales? Zero.

So the lesson is (unless your product is a multi-sided business like Facebook, where users are not paying customers) do not invest time and money to get more traffic. If you do, make sure to TALK to those people, because validating the product is more important than vanity metrics like how many likes you got on Facebook.

If there is just one thing you should learn, it is: Just speak to prospects and extract their pain, then sell the painkiller (before building the product). If they are willing to buy, do take their money and invest that money into building the product.

What I learned from my failed startup after 2 years, 300 users and zero revenue was originally published in 10,000 Ways to Fail on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Ben Yoskovitz

It’s been a number of months since I announced that we sold Standout Jobs. In that time I’ve gone through a myriad of emotions and cyclical arguments in my head about the entire process of starting Standout Jobs, running it and selling it. I’ve read a number of great (and heartfelt) postmortems of late, and then read Eric Ries’ blog post: Stop lying on stage. I appreciate Eric’s point-of-view, and I’ve had similar experiences watching people on stage, publicly addressing an audience and omitting key points of their “startup’s story”. Investors do it too. Everyone does it (I think it’s human nature.) But there’s a big difference between “on the record” and “off the record”. People should be smart enough to know the difference. And there are some bridges not worth burning (at least completely.) Even more importantly, there’s just some things that aren’t meant for public consumption. Perhaps in those cases the stories (or “legends!”) shouldn’t be promoted whatsoever, because they’re only half-truths…

One thing is certain: Success is never as easy as it seems when someone else talks about it, and failure is rarely as dismal as it seems either.

“Overnight successes” are generally bullshit. No road to startup success is without big, massive road bumps. It’s called a rollercoaster for a reason. On the flip side, failure is rarely so crippling a blow that entrepreneurs can’t pick up and keep going. Everyone fails. “Out of the ashes…” and all that.

So in reflecting on all of this (and more), I’ve decided to write the Standout Jobs postmortem. And the only way to do so effectively, publicly and hopefully with the end result of helping other entrepreneurs, is to reflect on my own performance and efforts.

Although we did exit Standout Jobs it was not a financial success. In fact, personally, I have less money now than when I started the company. Initially (I can’t remember for how long) I wasn’t paying myself. When we raised financing, I paid myself a fair salary, but then cut it down when the company was struggling. At the end, I wasn’t paying myself for quite awhile as well. Such is life when you decide to start a company. High risk = high reward (or not!)

I am pleased (as I indicated when I announced the exit) that we found a buyer for Standout Jobs. It was a great and difficult experience to go through. It was a true learning experience. The technology we built was solid, and I do honestly hope that the acquirer is able to leverage it with great success. You can certainly see in the marketplace today that a number of players have been working on enhancing employer profiles, increasing employer branding and social recruiting opportunities for employers. We were onto something.

Timing Sucked

Our timing was terrible. We launched the paying version of our application in the fall of 2008 about 5 minutes before the economy collapsed. Very few companies were hiring. I got feedback on sales calls like this: “That’s a great product, really love it, but we won’t be hiring for another 18 months or so. You have anything to help us fire people?”

We knew the economy was heading south, but we had no idea how bad it would be and how long it would last. And we failed to react quickly and aggressively enough. In fact, I think most failures of CEOs and startup founders fall under the category of, “didn’t react quickly and aggressively enough.” I’d say it’s fairly rare that a startup overreacts to something and changes too radically. In 99.9% of cases it’s the opposite: startups don’t change fast enough. But making aggressive, fast changes takes bold, bold leaders.

Not Bold Enough

Simply put, I wasn’t bold enough. It took too long for me to sound the alarms loud enough. There are a number of reasons for this, and I’d say they’re quite common. For starters, I’m not a loudmouthed egomaniac. I don’t think you have to be, but you do need a big ego to survive. I have a healthy enough ego (most days!) but it did take a beating during the course of Standout Jobs. It’s not that hard to get to a point where you believe that everyone else knows better than you do. And having to tell your investors, Board of Directors, employees, family, etc. that what you told them would work isn’t working is just plain hard.

I absolutely believe that taking a more analytical approach — driven by Customer Development and Lean Startup principles — can bolster your sagging ego and help you make rational, honest and difficult decisions.With Standout Jobs, I wasn’t rigorous enough in this process. I won’t make that mistake again.

Market Understanding

I didn’t have a strong enough understanding of the HR / Recruitment market going in. I’ve written about this before and I see countless entrepreneurs make the same mistake. They look at a market objectively and think, “I can fix that!” only to realize when they get neck-deep into it that there are a whole bunch of issues they didn’t understand.

I just didn’t do enough homework. And doing homework while you’re writing the test as fast as you can is pretty damn hard.

Having said that, I do think that I did a good job pushing my way into the industry leadership, networking, communicating Standout’s vision and catching a good sense of where the market was heading. And in some markets, brand awareness and brand building amongst the evangelists and leaders is critical to gaining exposure and generating buzz. It can provide a false sense of success, which is something to be wary about, but it can also add significant value.

The lack of market understanding ultimately meant that we couldn’t match the right product to the right market at the right price.

Product Development

I had an exceptionally strong team. Best I’ve ever worked with. But in reality we didn’t code and launch fast enough. We didn’t get product into customers’ hands fast enough. We were fast, but next time I’ll move faster, and iterate much more frequently. Of course that’s easy to say, but I think a lot of developers aren’t as comfortable as they need to be with this strategy. The fact is that having a specification and building to that specification is a lot easier for a developer; constantly changing requirements, moving things around, cutting features, adding stuff, circling back with feedback, etc. makes a developer’s job harder. More rewarding. But harder.

In the future I’ll focus a lot more on a Minimum Viable Product (MVP) and getting it into the hands of customers as early as possible. And even more importantly, I’ll solicit real, hard feedback from them. With Standout Jobs, we did things in a slightly incorrect order, which distorted our view of reality.

Shoving Things Down the Market’s Throat

If you find yourself in an argument with a market, you’re very likely to lose. As we got Standout Jobs into the hands of customers we saw a few troubling issues. People weren’t using it as actively as we had expected. People were still following the same bad habits they had before even though we provided them a “better way.” U1ltimately changing behavior is extremely hard. It’s possible, but you need to be very, very creative about it.

I didn’t realize just how much of a behavior change we were asking people to make. We did find ways of circumventing people’s unwillingness to change, but we never committed to those strategies fully, in part because they didn’t work quickly enough, and in part because we were stubborn.

Simplifying the Value Proposition

I was able to simplify Standout’s value proposition to the point where it was clear, but that’s not always enough. Part of the problem was that our value proposition lacked immediacy: “Invest in your employer brand and over time you’ll hire better fits into your company at a faster rate.” The problem is with “invest in your employer brand” — too few people truly have time for that (although they should!)

I didn’t make a strong enough case for tying the value proposition to something immediate that HR could sell internally to their bosses. It’s important to note that “selling a value proposition” and “delivering actual value” are two different things. I remember a sales call once with two people in an HR department. This was the second call. We were doing a web demo. As I was presenting, the new person on the call said, “We already have something like this. It’s [name not included here]. It does what you’re talking about.” I was surprised that the first person I had met didn’t bring this up since the other product was somewhat competitive. It turns out that neither of the two people even knew the URL of the site that the competitor had launched for them. The competitor had managed to sell their solution to this company, and the company didn’t even know where that solution was online. That was surprising and demoralizing. The competitor had managed to “sell their value proposition” extremely well, but whether they were delivering on value was a different story. Please note: I’m not arguing that you should sell a good value proposition and not deliver actual value, but you can’t get to delivering actual value if you can’t sell a good value proposition.

Value propositions need to be super clear, straightforward and deliver (or at least claim to deliver!) immediate results. Tying value propositions to making more money is best. Saving money is second best. Everything else is tertiary…

Raised Too Much Money, Too Early

I raised too much money, too early for Standout Jobs (~$1.8M). We didn’t have the validation needed to justify raising the money we did. Part of the reason for this is that the founding team couldn’t build an MVP on its own. That was a mistake. If the founding team can’t put out product on its own (or with a small amount of external help from freelancers) they shouldn’t be founding a startup. We could have brought on additional co-founders, who would have been compensated primarily with equity versus cash, but we didn’t.

I had never raised venture capital before. Raising the money felt likewinning. It felt like all (or most of) the justification we needed. It set us on a path of building a bigger product than we should have, and committing (falsely) to our own assumptions of what would work, without fully testing them.3

Having said that, I also realized at some point in the process — especially as a result of the recession — that in order to survive we would have needed a lot more money and a lot more time. I estimated about $5 million and 3 more years. That wasn’t going to happen. But as we got deeper into the market we recognized that to punch a real hole in it would require lots and lots of capital. So while we raised too much, too early, we also weren’t in a position to raise a lot more, later when it would have made more sense.

Raised Money Over Too Long a Period of Time

Although I did raise too much money too early, it also took too long. The money was raised in two major tranches, but we also left room for key angel investors to come in at various stages. The entire process took 9–10 months at least. As a result, I spent too much time raising money, which was a complete distraction from running the business. That’s the double-edged sword of fundraising — you have to do it (and it’s hard) + it’s distracting and in some ways detrimental to running your startup. I saw raising money as a form of validation, and so I was willing to invest in it. But it’s really only validation that someone will write you a check; not that you’ve got a strong, scalable business. The challenge with raising money is that once you start, it’s hard to stop.1 The money is used to grow your company, which often results in more expenses. More expenses, without revenue to support them, means going back to raise more money. So you end up on this conveyor belt of raising money, which is difficult to get off of.

Investor Management

I had a great group of investors. This included Montreal-based venture firms and angel investors in Montreal, New York and elsewhere. Unfortunately I didn’t manage and leverage my investors enough. From a leverage perspective, I didn’t do enough to extract value from my investors. I didn’t engage them enough for introductions to potential partners and customers. I didn’t follow through as frequently as I should have.

I think the key to successfully managing and leveraging investors is consistency. You need to be consistently knocking on their door, asking for help with specific issues, and providing them the ammunition they need to promote your startup. Investors are busy people. Venture capitalists are managing portfolios and chasing new deals. Angel investors are doing the same, and often times have their own startups they’re working on. You need to earn mindshare and attention.

On the flip side, you can’t listen to everything your investors tell you. They’re not infallible. If you disagree with them you need to step up and say so. It’s not easy, especially for first-time entrepreneurs, but it’s critical. The relationship between investor and entrepreneur isn’t parent-child. It’s partner-partner.

Go-To Market

When we were getting ready to launch the paying version of Standout Jobs, we decided to pursue a channel partner strategy. This meant providing partners with a white label version of the Standout Jobs platform so they could resell it. In principle it made a lot of sense: they had existing customers, market share, mindshare and experience selling into the HR market. And we had a lot of interest. But looking back it was too early for us to be seeking partners. We didn’t know ourselves yet how to sell the product, to who and for how much. Without that information we didn’t provide channel partners with enough of a “sale-in-a-box” that they could execute on.

In some ways we tried to offload responsibility of selling our product to our channel partners. It worked, to a degree, but not well enough. And when the recession hit, everyone in the HR / Recruitment space got clobbered. Our partners recoiled and focused on their core, and we were left holding the bag. I still believe there’s immense value in leveraging channels for sales, but only after you know how to sell your product effectively; the channels then provide scale.

Big Pivots

At some point in mid-2009 it was very clear that Standout Jobs was in trouble. The recession was still holding a death grip on the economy, we were running out of cash and traction was middling at best. It was a difficult time. I don’t remember the exact order of events, but we decided to pivot in a big way. This was an “Odeo into Twitter” moment, where we were prepared to shutdown Standout Jobs as we (and everyone) knew it, and resurface with something completely different (although still relevant and emergent from our experience.) It was an exciting point and truly re-energized the founders and the team. We had some rough ideas, brainstormed furiously and put together a super-basic prototype of what we envisioned. It was a B2C play around identity, referrals and recommendations. There are a number of startups now that are playing in that space.

We pitched the concept to our Board of Directors but a decision was made to “stay the course.” I have no clue if the new idea would have generated any traction, but I should have fought harder for it. We certainly didn’t have much to lose at that point. I don’t think many startups really go through this kind of massive, transformational change. It’s scary. And inasmuch as people talk about pivoting (although this was more like a “scrap and restart completely new”), I don’t know that most entrepreneurs and investors really have the stomach for it.

I also tried a few smaller pivots. I relaunched the website and repackaged the product into a few different offerings. Also added a service layer on top of the product. The goal was to take what we had and try to find a market. I also wanted to simplify things and focus on lead generation as much as possible. These smaller pivots and market adjustments actually generated positive response, but I didn’t have the time or resources to execute on them aggressively enough.

Bullshit & Politics

I’m not a fan of bullshit or politics, but unfortunately these are both realities when running a startup — particularly one that’s not performing well. You have to be prepared for it. I’d recommend having one or two very strong outside advisors — experienced entrepreneurs that have “been there, done that” — to lean on when you get to this stage.

Creating Value

In October, 2009 we let go the bulk of the team. We held on for as long as we could because we were engaged with potential acquirers and felt that the team would add value in an acquisition. And there were a couple of acquirers where I think this was legitimately true. Unfortunately, they didn’t see it that way! Eventually I made the decision to let the team go. It’s a shitty experience, but not as bad as you might think.

Throughout the acquisition process we worked to create value. The team. Our partners. The technology. Us (the founders.) It’s a very similar experience to raising early money; often you don’t have a lot of proof of anything, but you try and tell a good story. And fundamentally, I believed at the time (and still do today) that we were doing something right in terms of where recruitment marketing and branding was headed. The package wasn’t quite there, but combined with other pieces of the proverbial puzzle and I saw the potential for strong value to emerge.

Perseverance

With all of the mistakes I made and all the difficulties faced by Standout Jobs, I’m still pleased that we (and I) persevered. From the fall of 2009 until the acquisition closed, Standout Jobs was really just me looking to get a deal done. Sort of a “last man standing Ultimately it was too little, too late, but I’m still glad I went through it.

Having said that, I think founders have to be very cognizant of their startup’s lifecycle. When it’s time, put a bullet in it and move on. Whenever I had the “should we kill it?” conversation with my founders, investors or Board of Directors I always felt that I could extract more value. And I wanted to try. The experience was worthwhile.

The Future

I’m no longer involved with Standout Jobs. The acquirer has been working for some time on the technology and I look forward to future announcements from them. I’m still actively looking at the HR / Recruitment space — frankly, I feel like there’s unfinished business there. A lot of entrepreneurs have reached out to solicit my feedback on their HR / Recruitment startups. I’d encourage you to keep doing so. I’m looking for the winners in there; I’ve gotta believe they’re somewhere!

I’ve now moved on to Year One Labs, an early stage seed accelerator based in Montreal. So I’m (sort of) on the other side of the table, although I can’t ever really picture myself as an investor. I see myself more like a guy that wants to help other entrepreneurs build successful businesses. Not because I’ve sold a company for $100M yet, but because I’ve been through a lot, seen a lot, and like to roll up my sleeves and get dirty. And at some point in the future I will found another startup (or two, or three, or four.) Once you start, it’s hard to stop. Even with the ups and downs, bumps and bruises.1 I’d rather not repeat the same experience I had with Standout Jobs (at least not in its entirety), but I’d take this life and these experiences over a “regular job” any day.

A Postmortem Analysis of Standout Jobs was originally published in 10,000 Ways to Fail on Medium, where people are continuing the conversation by highlighting and responding to this story.