Hacker News new | past | comments | ask | show | jobs | submit login
Why I turned down $500K and shut down my startup (medium.com/timoth3y)
648 points by jason_tko on June 9, 2016 | hide | past | favorite | 175 comments

Hi. Tim here.

I'm delighted that this article struck such a chord. I'll try to answer the most common questions here. I wish I could answer everyone directly.

1) I called it off before anyone sent money or quit their jobs. The only one who lost money or a job because of ContractBeast was me. If the money was in the bank and the team on board we would have gone ahead. That's why I had to make that decision when I did.

2) I'm not saying there was no solution. There might have been, but the team and I could not find one. Think of it this way. You and a team decide to summit a mountain. It's a high-risk endeavor. After weeks of going over your maps and equipment you just can't see a plausible way up. Do you call it off or set out hoping you'll be able to figure it out. It doesn't mean no one can do it. I means I could not do it with that team and that equipment.

3) Why didn't we leverage the contract approval features that customers loved? We tried. The problem was that those kinds of approvals were not core workflow for SMBs. It was useful when importing contract templates, but was not used much after that. Nice feature but not important enough to get companies to sigh up for multiple seats, which is what we needed.

4) Whats going to happen to the code and to Tim? No decisions yet. I'm open to suggestions on both counts.

When PayPal started, they were beaming money between PDAs. Then after a while when their curves were no good, they noticed that some confused users thought that their Confinity website that described how to beam money, was actually the place itself to transfer money to others. Then they pivoted. Then this new product was not viral. Then they started paying $10 when you open the account.

Please don't down vote this comment. He is making a salient point about why it might not be a good idea to quit at such an early stage. Whether it was the right decision for Contract Beast or not, he is trying to provide a counterpoint to the idea of giving up by providing an alternative anecdote. Some people in a similar situation could use the boost.

Yeah, but Tim already addressed that scenario when he said that nobody but him had quit their job or lost any money yet. The PayPal team was already well into being a committed startup.

While your comment is right from my position (I often help startups to solve them problems) thanks for using "salient" - new really nice word goes right in to my dictionary.

The "salient point" as you put it suffers from a huge acute case of selection bias and survivorship bias, two deadly diseases that kill the argument immediately after it's born.

Indeed. Not to mention the Internet was basically a wide open green field to build companies on in those days. There is no shortage of B2B focused web-based software in 2016.

I agree with the huge difference between 1998 and 2016 decisions. Soon it will be like starting a car company in 1930s: was possible in 1905, became impossible in 1930

Yeah, just like with Tesla...

Changing behavior is hard, many startups try only a select few can. Adjusting behavior an easier but less rewarding outcome.

They had already raised $4 million for the PDA idea. Or rather, the MVP. The $4 million was famously beamed into their account via PDA.

Loving your article.

1) You can describe the market in a few sentences, even to people without a background.

2) You can track user reaction without the need to ask them.

3) You know that most people don't understand their problem and therefore can't give good feedback via feature requests.

4) You understand human nature. People want to see a payout fast, before investing real energy into something.

5) You can pull the plug when the setup is not right.

Hope to work together with more people like you in the future. Are you currently looking for a CEO position in a start-up btw? ;-)

You mention that you might write an article on distinguishing the tangential feature requests from the useful ones. I would really like to read that :) Especially if I could send it to our product managers, because our product has been in a cycle "we need an enterprise sale" > "potential customer mentions a feature they would have liked" > "we scramble for a month to write the feature and close the deal".

To be honest, it is much better now, but as a QE on the project, now I get to deal with so many half-abandonned/half-finished features.

The key is to ignore the feature request, and focus on the problem.

Users don't come to you with problems, they come to you with shitty solutions.

You need to take their solution, reverse engineer their real problem from that, then work out a good solution for that problem that fits well with your product.

"My job is not to give the users what they want, it's to give them what they need."

That's a bad place to be stuck in. I'll see if I can put something together that makes sense and is fairly comprehensive. At the moment, a lot of it is "I know it when I see it" but that's not exactly helpful.

Fortunately we seem to be moving away from that now-days :)

And I have talked with our guys and I can sort of see it from their view-point. from their point of view it often is the hunt for the last `checkbox`, the last necessary tick somewhere on the customers requirements page.

In their mind it often seems as a simple calculation, on one hand potentially so much $/year from big-corp vs 2xManxMonth to get a new feature over the line? No brainer.

An I am struggling to somehow explain that you need to add much more to those two developer months, because with every feature there are bugs and regressions and customer tickets, e.t.c. and suddenly it takes one developer in perpetuity.

Isn't a big part of it the client saying that "it would be nice if..." versus "we can't use this unless"?

Much as a salesman can tell when a customer is saying "I would most certainly give you money if you turned your product upside down and painted it blue", which is correctly translated as "I will never buy your present offering."

That dynamic is very different for one size fits all software than it is for consultancyware, though.

I had a very similar experience to yours (with the exception of partners and investors). I was building a staff scheduling system, launch with beta testers who tried it out and then suggested they'd start using it when it had feature x or y. I'd implement feature x and then they'd say they'd use it when they had feature z.

I came to realize that the challenge is in the changing costs. They already had a product that could do more than what they could do with the systems they had at the time (mostly excel). It did a bunch of reporting and shift swapping etc. etc. but there was no way it wasn't getting momentum.

Thing is, I just wasn't passionate enough about it to make it a product I would love working on for the next 10 years.

A few people here say you're burned out, maybe you are, but maybe there are other projects you're more passionate about.

The project I'm currently on I'm not madly passionate about as a product, but other people love it, and it is fun to move the levers and see the affect on traffic and the (potential) business.

You're definitely not alone in your thoughts on this one, I can appreciate where you're coming from. Hopefully you look back at this as a great decision.

Better things ahead!

(great writing style btw)

Hi tim, nice reading. It put balm in my heart.

Well, I thought I was crazy some times in my life (when I pulled the plug of my own company) for putting my life and my sanity on par with money. I was getting broken, I had a constant flow of ... 70+ /hrs job paid 35 hrs a week and even though I had customers but I was chaining more and more burn-in on burn-out. I was seeing my benefits diminish and my life sucked out.

But I did the right choice retrospectively. When clouds of stress disappears emotional reactions loosen up, then most of the time it shows you that rational thoughts such as the one you are exposing are right.

Risks have to be rationalized else you can get sucked in a gambler attitude. I guess some entrepreneurs are not guarded well enough against the "gambling/irrational risk" addiction that can be fired up.

It is hard because we are driven to entrepreneurship by emotions, and business decisions are best done in a cold sociopathic kind of state of mind.

You have all my regards and I wished I could have written such a concise and clear essay on the difficulty to live with decisions that are right and seem wrong because we human have doubts, emotions, dreams...

Thank you. I'm glad it meant something to you. TO tell the truth I was a mess the first week after deciding to shut down. No matter how many ways I could "prove" to my self I was doing the right thing, it still felt horrible.

I'm better now, and this discussion on HN -- even those who disagree with me -- really helps.

Lucky you, I pulled the plug a little to late, and now I pay a dear price.

Risk aversion is NOT bad. For 1 success they are hundreds of failures. Even though I accepted the game, it retrospectively feels like going for business is signing a pact with the devil. Either you win, and it is okay, or you lose and damages are doubled since your are marked with the seal of failure.

We live in a time where people want heroes and success stories, not reasonable persons that are boringly facing uncertainty.

When you take a risk of winning, you also take a risk of losing.

My epitaph will tell: "Si l'échec est la meilleure manière d'apprendre alors de mon vivant, j'ai vaincu Karpov et Kasparov".

I made the mistake of going ahead. 5 years later and little to show (but a frustrated sales staff and confused investors) I gave up. Wish I had the balls to give up years earlier. I could have worked on something with a better outlook, which would have benefitted everyone more. Remember, its not "do this or give up"; its "do this or do something else".

"I'm not saying there was no solution. There might have been, but the team and I could not find one. Think of it this way. You and a team decide to summit a mountain. It's a high-risk endeavor. After weeks of going over your maps and equipment you just can't see a plausible way up. Do you call it off or set out hoping you'll be able to figure it out. It doesn't mean no one can do it. I means I could not do it with that team and that equipment."

From what I've read (and I could be wrong), it just sounds like you burned out. From personal experience, it's super difficult to keep up the energy and morale when you're either solo or semi-solo (when your cofounders aren't full time like you are). Part time cofounders are better than no one, but they're nothing compared to a full time cofounder who's with you in the trenches.

Good job on lasting as long as you did on that death march.

Tired certainly, but not burned out. If we could have come up with an approach to solving the problem, I would have been 100% on board.

I have no problem working 70+ hour weeks for something I believe in. I've done it before, and there's a good chance I'll do it again. Just not on this project.

Isn't uncertainty a major characteristic of a startup though? Even if you guys had a hypothesis that you believed in, would it necessarily be correct? I'm just saying that maybe you'd have more faith if either you weren't working 70 hour weeks or you had another full time co-founder

Based on what I read, it wasn't that there was no way to make this work - as you state here.

It's that you didn't want to stake your future on an uncertain outcome.

Nobody can argue with you that such a decision was a bad idea. If you, the founder don't want to do it - it will fail. So I think this just wasn't your passion play and you can't go down this road without being passionate and come out the other side in one piece.

That said, if every founder thought this way we wouldn't have most of the companies that we rely on today (not just startups by the way) - maybe that's good maybe that's bad.

> Based on what I read, it wasn't that there was no way to make this work - as you state here.

It totally was! He had no way to solve the fundamental problem of the software - making people use it ALL the time, for multiple (paying) users. If the software was doomed to be one licence for an office of 20, where it is used sporadically for one or two infrequent use cases, it was doomed, and the only hope was a pivot. No one should start a business hoping to pivot.

> It's that you didn't want to stake your future on an uncertain outcome.

Again, no it wasn't. It was that he didn't want to chase hoping there might be a solution, because there may not have been a solution at all. If your whole business plan is "raise cash and hope we pivot to a good idea", is that really a solid plan? Why not just pivot before getting the cash? I have never heard of anyone proposing to raise cash based on an as yet undecided pivot.

> That said, if every founder thought this way we wouldn't have most of the companies that we rely on today

Prove it. No company I can think of knew pre-funding of a huge flaw at the core of their product they couldn't solve, and raised cash so they COULD pivot. Most pivots happen because a company finds a small element people love, so they move towards that. Startups don't go in hoping to pivot to an as yet undecided new plan. I mean, that just seems non sensical to me.

Prove it.

There are other examples in this thread. A pivot is exactly that, something you need to re-engineer or change the market on to make viable.

Reddit is a good example. Burbn/Instagram another. Flikr even better.

If your whole business plan is "raise cash and hope we pivot to a good idea", is that really a solid plan?

As with most things, the answer is "It depends." Taking money can be a forcing function on a pivot. If you have a solid team and know that there is a market, then you seek hard for a solution - if there is no solution in the market then you take the company in a different direction. That's why team is so important - ideas fail.

I'm very interested in your learnings.

I've worked on enterprise collaboration software before, and came to the conclusions that the users will favour using the simplest thing for the task in hand (email or excel) no matter what SAAS products they have.

The trick then becomes 1. sell to management and get them to gamble on enforcing it's usage, (maybe by taking away the other tools, extensive training), or 2. have something that works at a grass roots level (e.g. dropbox being used to work around IT constraints) .

I think I may have just restated your post, oops!

I keep wondering if the future for workflow tools might be to unobtrusively monitor user interactions by hooking into the email client, and have an intelligent Clippy-like service which prompts and decorates their tools i.e. prompting to use ContractBeast if a contract is attached to an email (or in fact just doing so), and to display relevant information as and when needed. There was some CRM system extension for gmail years ago which I remember being radically successful.

Could something like that have worked out for you?

*and server in order to provide analysis, archiving etc.

This is a good idea.

As another example, if I had to enter tracking IDs into some app to have a nice view of when my packages were coming I wouldn't do it.

But gmail picks them from my email for free, so I use the app every day.

Tim, I only have your perspective to go by, however, from what you describe, I agree that you did the right thing.

On the bright side, you still have Contract Beast on the back of your mind and if you ever do think of an interesting solution then you'll be in a good position to test it out.

Nice article. I just had a similar experience: after a bunch of work building a product, I came to the realization that the problem I was trying to solve just wasn't urgent enough, and the organizations I was trying to sell to just didn't have it together enough to decide to buy. So ultimately I decided to shut things down, though I did manage to salvage some of the code for reuse in later projects. Ultimately, entrepreneurship is an experiment, and sometimes what an experiment teaches you is that your hypothesis was wrong and you should try something else instead.

If team & investors wanted to move forward, did you discuss letting them (without you)? Basically just walking away, with no/low strings attached. I'm just curious, because sometimes I pick up on an "if I can't have it, nobody can" type attitude. If you made that offer and they refused, it's not on you.

I think you made the right choice, I would have done the same and don't think you should be judge worse for it. The whole thing was an experiment, your reason seems like a good reason to cut your losses personally. Before investment, that's Ok.

I would have been OK with it, but I don't think it would not have worked. I developed most of the code and was the only one with significant startup experience. That said, I don't know if the rest of team ever discussed it with the investors. They did not bring it up with me.

I don't know man, $500k is a LOT of money to even pivot to the next Uber for X. I might be totally wrong, but I think you are just burned out. Best of luck!

Personally, I think more healthy skepticism like this is needed in startups. Everyone being completely convinced they can pivot to the next Uber for X is what scares me that there's a bubble and makes satires like HBO's Silicon Valley so poignant.

Bravo. On a different note. Why is your username is displayed in green ?

No one manages his money as carefully as his own. If you were as clear and succinct in your description of the situation to stakeholders as you just made plain here, and they were willing to pay for the chance of success or the effort toward success, the project should have gone forward.

He made it clear, though, that it wasn't just his stakeholders' money he was worried about - it was investing his own valuable time and energy in a problem he believed to be fundamentally unconquerable. That, to me, is a far better reason to not go forward.

It sucks when you realize you have built something that users like, but they don't really NEED. I like the good habits analogy - I built several great workflow apps for a Fortune 500 company in the past few years, but discovered most users don't really want the yoke of workflow and there wasn't enough immediate lift to tempt them.

Sorry man. Good call not to waste a year of your life.

"It sucks when you realize you have built something that users like, but they don't really NEED"

That's a great point. There are a lot of intractable problems that everybody wishes could be "solved" but the reason they're intractable is that solving them simply requires working harder. They can't be solved with cleverness they just require doing all of the work, rather than doing as much of the work as you absolutely have to. A ton of "solutions" just shuffle the work around. So it's like you have a clean sink, but if you want to use the oven you have to find another place for the dirty dishes. One pseudo-solution that doesn't actually reduce the work is just as good as another, so there's no NEED to switch.

The underlying idea behind what he did here is sometimes called Ethnography. There was another great article a while back on this going on at adobe/photo shop: https://medium.com/startup-study-group/my-two-years-as-an-an...

As far as tools go, ethnography can be very powerful in the right hands.

Great comment. Fantastic article.

I wonder if they considered involving both sides of the contract from the get go. When I've negotiated small-mid size deals with other tech savvy folks, I've often thought a two sided chat style interface that I could use sitting next to someone or if they were across town would be ideal.

The way I conceptualized it would be a 3rd party tool for making deals where the main feature is standardized clauses for minimal lawyer involvement. Eg. Need a standard confidentiality clause? (Drag Drop). Boom. Let's do business.

Commercial lawyers would hate it, but that's sort of the point.

I think the primary issue is that when you start redlining, everyone has their workflow and the side that's in the "position of power" will use what they feel like using.

"Oh check out this contract at FooBarContracts"

(counterparty opens link, copies text into word doc, edits)

"Here's the latest DOCX with my revisions."

It could be an iterative process, with niche domain and custom clause support. For small-mid business people interested in GTD, I think there would be enough utility gained by both sides to remain on the platform. For experienced business people, involving the lawyers is an inevitable drag on dealmaking.

I bet people involved in frontline sales for (eg. software) would love something like this to exist for fast closes. There are your shadow unpaid product evangelists.

You're assuming both sides 1) play nice and 2) actually collaborate in that way. A lot of the time it is David (small corp) vs Goliath (huge corp) where David has to accept terms of Goliath on their standard deals or risk not completing the deal.

Ethnographers tend to be rather hands off (/against) directly changing who they're observing. Contextual Inquiry (http://www.usabilitynet.org/tools/contextualinquiry.htm, http://www.amazon.com/Contextual-Design-Customer-Centered-In...) is a fairly light weight method and I think would benefit a lot of startups.

Depends on their school of thought. You could go full gonzo anthropologist.

"When users are unhappy but can’t explain exactly why, they often express that dissatisfaction as a series of tangential, trivial feature requests."

This bit resonates the most with me. I worked on a project worth little traction where we'd keep getting feature requests from the client facing team members for things that were of minor value but sometimes major effort. It grinds you down over time as you realise there's no real demand. Eldorado isn't over the next hill.

Sometimes it feels like the people giving feedback are just too eager to please you with positive feedback.

> Sometimes it feels like the people giving feedback are just too eager to please you with positive feedback.

This is an important observation. As someone once said, "no one wants to crush your dreams". If you present people an idea for a business plan, most people will say that is sounds very interesting, nice opportunity, they'd definitely consider buying that, etc. If you show them something you made, they will say it's great and politely have a little conversation about it.

It is very easy for perennially optimistic (/self-deluded) entrepreneurial types to take this kind of feedback as validation, when in fact it is nothing of the sort. The only validation is this: Are they giving you money for it? That is when you know you've made something of value, not a second before.

Users mean well. Basically, they want to be part of the process. They are trying to help you solve the problem. It's way too easy to fall into the "If we just had this one feature" trap. Sales staff love coming up with feature requests and the developers love having something they can sink their teeth into.

It feels like progress, but it's not.

I have a long list of features that I want to implement at some point. When I get feedback from users for those same features I move them up somewhat in my priority list. If it's something that's not on my list I add it to the bottom of the list and re-evaluate it's importance a few days later. I think it is a good way to avoid immediacy bias and keep a handle on what's a true priority.

One of the frustrations of working under a boss with little software experience; they keep believing this

"I was deciding whether this venture was worth committing to another year of 70+ hour weeks. I need a higher level of certainty than investors do because my time is more valuable to me than their money is to them. Investors place bets in a portfolio of companies, but I only have one life."

That's the key quote in the article. It's a fair decision from his standpoint but I wonder if saying that will lead investors to question his determination in the future (if he tries a new venture). I suppose the investors could also appreciate that he didn't want to waste more of their money if he didn't believe in the product.

If the situation were really "take the money and do 70+ hours a week for a year" versus "shut down the business" then I'd agree, but that's a false dichotomy. You can run a startup putting in far less time than that; putting in long hours is a choice. You can bring in a team or outsource the parts you don't like. It makes it harder to succee but it's an option. You could (depending on lots of caveats) simply hand the business over to someone else.

I respect the author for admitting he didn't want to run the business, and I realise it was his choice to stop in the face of any other options, but I really don't agree with the idea that running a startup requires 70+ hours a week and if you're not willing to put that time in you have to shut down.

It's not about time or money. It's about wasting time on something while you're not motivated anymore because you know it will fail 99% sure. If you can't commit to it, you make that 100%.

Absolutely. I'm not sure why everyone else in this thread seems to be focussing on the "70+ hours" part specifically. I agree with your interpretation.

"outsource the parts you don't like" This doesn't work from my personal experience and others seem to agree. Myself been apart of a few startups learned you never outsource your core competency and doing so is usually suicide no matter how good you think you are at managing.

It's easy to see when you realize your goals and your outsourcing entity have different objectives which are at odds with one another.

If your core competency is something you don't like doing then your business is probably going to fail regardless. Keeping that in-house should be obvious.

Although the author phrases it as "70+ hours a week", my assumption is it's not the hours per week that he doesn't want to commit to it, but the total hours involved that it's going to require to solve the situation.

Whether that's 70 per week or 5 hours per month, the total amount of hours needed is going to be x,00 or x,000 - and that's time he simply thinks is not a priority or valuable to him.

There's a total number of hours of work needed to build something, but they don't all have to be put in by one person. It might be one person doing 70 hours a week, but equally it can be two people doing 35 hours each (probably more like 40 hours actually to account for comms, but still, not even close to 70). The hard part is finding someone who can do the role.

I don't agree on the assumption that the total number of hours is a given. If you're working on something 70+ days per week for an entire year, your productivity is going to drop. If you work less, but are refreshed when you start working, you'll be way more productive. Especially if it requires any amount of thinking.

I'm building a startup and I wish I could accomplish everything I need in 70 hours a week -- it would give me so much more time to work on the other parts of the startup that I currently don't have time to build out.

    but that's a false dichotomy
It's a false dichotomy for self-funded/bootstrapped businesses. But if you consider yourself a startup, you have to deliver growth. It's that pressure that leads to the 70+ hour weeks. It's entirely possible to own and run a business while still putting in reasonable hours. But it's unlikely that business is a startup, by Paul Graham's definition of the word.

For reference, Paul Graham defines a startup as:

    A startup is a company designed to grow fast. Being newly founded does not 
    in itself make a company a startup. Nor is it necessary for a startup to 
    work on technology, or take venture funding, or have some sort of "exit." 
    The only essential thing is growth. Everything else we associate with 
    startups follows from growth.

I personally consider that definition to be bollocks. To me, the defining characteristic is the intent of the company, in terms of it's ultimate size / position. IOW, it's "where you're going", not "how fast you're planning to get there".

I know it goes against the currently accepted groupthink, but I don't believe growing fast is the only way to grow a big company. Or rather, it might be better to say that "at any given point in time, it might or might not be important to be growing fast".

Take establishing a dichotomy between "self-funded/bootstrapped" and "vc funded". I would call that a false dichotomy itself, since it's not an immutable characteristic of a company. You can bootstrap for years, then decide to go chase VC money when/if you need it to achieve your goals.

There's another definition (or interpretation) of the word "startup" by Steve Blank that I like even better:

"A startup is a temporary organization used to search for a repeatable and scalable business model."

The temporary phase ends when the startup evolves into a normal organization that executes on a proven business model (or pivots, or stops).

Another dichotomy may also be pursuing the growth at the behest of investor vs doing it on your own. Growth, or adding value too, can have different meanings to the investor vs innovator. Startups that make money become businesses.

This idea is key, regardless of what the dictionary definition of startup is. A startup cannot merely be a profitable business. If that were true many more startups would be still running today. But if you take investment of 10 million and you're positive cashflow of, say, 200,000 in your first year with a projection of 1 million / yr in 10 years, you will be shut down and sold off: Investors want AT LEAST a 2x return in that same timeframe otherwise it isn't worth it.

Perhaps a confusing example, since that startup isn't profitable during its lifecycle anyway.

yeah not a great timeline comparison, but the idea is a Nx growth translates to Nx return on investment at some point.

Really? Quoting Paul Graham as you would quote the Gospel? I agree with the comment above, that's the definition of startup according to PG, not THE definition. Especially not a definition carved in stone you can quote to justify a false dichotomy. What about innovation? It's not true that innovation comes only from growth. Geez I don't even think it's true all other startup features come from growth. This is what a VC that needs to grow its money would tend to let you believe. Oh, wait...

> Quoting Paul Graham as you would quote the Gospel?

Welcome to Hacker News.

Next up is praising Javascript as the end-all-tool for everything. The hammer for all the jobs!

Please don't make snide generalizations about this community, especially when they're self-refuting. It's a genre of unsubstantive comment we can do without.

> I suppose the investors could also appreciate that he didn't want to waste more of their money if he didn't believe in the product.

Yes, very much so. Startup investments fail all the time, part of the business. Better a clean shutdown than trying to eak out an exit with money that could be better spent elsewhere.

especially if your heart's not in it for whatever reason

>I wonder if saying that will lead investors to question his determination in the future

You could also argue that it proves his determination, if he does in fact decide to engage in a new venture.

> I suppose the investors could also appreciate that he didn't want to waste more of their money if he didn't believe in the product.

I didn't get the impression that it was more of their money, but rather the first injection, like a seed round.

If an investor needs 70+ hours a week of work from one person to consider them determined, I'd question their intelligence, commitment, or financial security, because hiring some help seems like the wiser decision.

I have to say, I don't agree with this part at all:

"But most of the time, customers don’t really want the the features they are asking for. At least not very badly."

Customer feedback drives an absurd amount of our roadmap at Cronitor. We have a good idea of the many shortcomings of our product and are constrained primarily by resources in developing it faster. When a customer -- especially somebody on a trial -- puts their thumb on the scale of a specific flaw or deficiency, we look at it as an opportunity to seriously delight that user and at the same time level-up the product for all users after. We don't build everything asked for, but I would say "most of the time, customers know exactly what they need, and we try to give it to them within our ability."

A specific example for us would be Etsy, who uses Cronitor on a part of their business and during evaluation asked for a couple API endpoints to expose more advanced functionality.

For evolutionary features, you're right. But I think the point in the article is that if you're trying to get to product-market fit, your customers' feature suggestions are rarely the ways to get there; you generally have to watch, think, synthesize, hypothesize, and iterate again and again to get to the solution that actually does what you need done.

That's a little too hand-wavy for me. I think you solve a problem, produce an acceptably bad solution, and as you get traction you improve it. You do it evolutionary because you're not Steve Jobs and improving something continuously is a repeatable, adaptable technique in a way that spontaneous invention isn't. If you never get traction, and can't crack it, then you invested a minimal amount and you can move on. A portfolio approach.

I think this is true for both big ideas and little ones. I guess there may be some nuggets of truth deep down in the cw that "users don't know what they want until you give it to them" but I think it's mostly an over-used canard.

I think product-market fit is more then just making sales. It's having a sustainable company that can "service" those sales in a sane way. If your company is completely back logged and getting by by cutting corner after corner, you're not succeeding.. you're teetering on an edge.

There's an argument for the mental health of the founders as well as the soundness of the company.

I think that's repeatable and adaptable for two reasons:

1) technology keeps changing and it's usually easier to just write new software to take advantage of new infrastructure or design assumptions or whatever

2) almost nobody who has the expertise to do so gets paid to research pre-existing software, test it out, and find something that already exists that does the job. However, there is a large financial incentive to sell people on why they should use your new thing

So, there is never-ending opportunity to sell something new that solves the same old problem. It's a marketing-driven approach. You're basically just exploring the frontier of what people are willing to pay for, rather than the frontier of what's technically possible. It's "there's a sucker born every minute" style repeatable.

Not that there's anything wrong with that. People would have had to pay for research/adaptation to find an existing solution, so paying for development of a brand new solution is the same money. And marketing is one of those skills that's necessary no matter what your approach, so laying a foundation on top of it makes sense.

They're just two different approaches. The big idea approach isn't hand-wavy, it's just less common than the marketing driven approach. I think maybe it seems hand-wavy when people try to wear the big idea's skin like a mask cuz they don't actually have a big idea and everybody's like "grandma, what big teeth you have".

> But most of the time, customers don’t really want the the features they are asking for. At least not very badly."

It is easy to agree or disagree with that because it is rather ambiguous and everyone has seen it go either way.

At least, I've seen it go both ways. It really depends on the context and most of all who the customer is. Are they paying for the product, will they be more likely to upgrade or pay if the feature is there, do they know that feature contradicts with other feature they already requested and so on?

Even silly things like customer is trying to be nice to you can interfere with the process. Because they don't want upset you and they want to be polite, they might ask for something trivial and hide something more annoying or bothersome.

I have seen this happen with me and design. I know a crappy design when I see it. It is annoying and bothers me. But, at the same time I wouldn't know how to tell the designer to fix it. If they press me I might make up something like "yeah, change color to beige" or something silly like that. I can imagine that happens with any domain where customer might not have as much expert knowledge.

the horribly over used Ford quote:

> if i'dve asked people what they wanted, they'd have said faster horses.

is applicable here, much more so than in the battlecries of every company making something no one wants for some hypothetical market that doesn't exist.

While I don't understand the author's biz/space enough to comment situationally, this is a key insight. People almost always miss this. Users want to get to places much faster, and much more confortably in the Ford example. They speak in solutions and it is an entrepreneurs job to translate this into problems, rank them, and provide actionable responses.

The flaw I believe in your example, could be a few things. possibly if you are paid by a customer directly & are more a consultant/contractor than a SaaS provider, well, that's how you get paid. However, generalizing about a feature, especially without behavioural feedback is dangerous. if it is very easy to do, of course do it. However, the risk of a feature is some subset of:

* value to customer

* conviction/data in that value prop. & feedback

* difficulty to achieve

* is it replicable. how valuable is this to all my customers? is it very valuable to a few, or semi-valuable to many/all.

This is again, highest level, even in the last point above you can see the thread fan out.

So, again, i am bot super familiar with the authors company but I agree wholeheartedly with his process of decision making. Consider it is possible that either etsy was a big client, thus worth retaining for markwt goodwill & rev, or that it was quite easy to open an endpoint to data you already had, and thus doesn't discount this methodology

The somewhat underused 3M quote (paraphrased):

> When someone is shopping for a drill bit, they don't want you to sell them a drill bit. They want you to sell them a hole in their wall.

If you're wondering, most people will put a nail or hook in the hole in their wall, and hang a picture or something. 3M would go on to sell them tape or other wall adhesives instead of a hole in their wall.

Rephrased to correlate to this thread:

> When someone is shopping for document signing software, they don't want you to sell them software. They want you to sell them a set of agreements already negotiated with their business partners.

Don't confuse the tool with the goal.

I agree with this and I think it compliments Ford, or at least my interpretation.

I've put a fair share of holes in walls and also fastened plenty of material together. No one would buy a drill for one hole in a wall but there is a massive amount of leverage in being able to put thousands in quickly, ect.

> don't confuse the tool with the goal.

I think this is the lens/acid test. For your correlation above, it sounds like it was harder to sell them automated agreements than it was for them to manually produce them. Or at least, the perceived opportunity cost was higher and the cost to educate them otherwise was higher than the authors profit marg.

edit: just looked at your profile; very nice array of quotes you have.

The weird thing is, isn't it obvious that the first thing to do is to replicate all of the functionality of the customers' current package? It's nice to get a laundry list of possible future features, but when testing indicates that people are only using it for the minority of their contracts which fit the software, that's a signal that besides the laundry list, the software is still incomplete. Did they really shut down due to an inability to prioritize enhancements? Kinda sounds that way, but runway is runway.

I was struck by that too. Most people actually know how to do their jobs, and what they need to run them.

I worked with some guys a few years ago that do vertical market software like this. They have like $12M in sales and 6 employees. Most sales is via referral, trade shows and partnerships with other vendors.

Not sexy stuff, but lucrative.

If paying customers are asking for features pay attention. If non customers suggest features, you should be extremely skeptical that implementing those features will result in sales

Maybe you're wrong. It's worth considering.

This story has a ridiculous amount of integrity. You did what was right, even when convention went the other way.

Future investor reaction to it will tell us what they think of actually bucking convention to do the right thing.

I guess that's why this top-down market hasn't been disrupted. This guy is seeing clearly. Cutting the old makes way for the new - it would be better if I did this with my own zombie business.

And now, the armchair brainstorming: focus on the "contract review and approval" immediate gratification and marginal user wins - if not sufficient benefit for them to buy, make it multi-month free trial, make it a year. After some "months of use", users get the delayed gratification. They become your sales force from within, and CIO's notice the long-term benefits, validated within their own company, and mandate its use top-down.

It's a long slow burn and mightn't work.

Still fascinated! Couple ideas using Crossing the Chasm (CtC):

1. Your vision is crucial to your determination. Your vision is disrupting SMB CLM with "huge gains in accuracy and efficiency". You can only start the fire with those also inflamed with your vision - those who care. It seems only CIO's (anyone else?). The CtC idea is to target those few adventurous CIO's ("visionaries") who want to leapfrog the competition with this new, unproven approach. Reach them through those very, very few CIO's who are excited by the idea itself ("enthusiasts") - just because it's a clever, efficient, elegant approach to a broken process. They exist, just not many.

So: if you try to appeal to users, it must be those users who are excited by what causes the "huge gains in accuracy and efficiency". Otherwise they'll carry the wrong torch to the CIO.

2. The other CtC idea is "niches": pick out the types of customer who would really benefit from your solution. e.g. inaccuracy causes chronic problems for them/losing customers/bad publicity; CLM is a dangerously high cost center; they can't keep up with sudden demand and are losing sales; they can't adjust to changing contracts, and lose opportunities; (new) regulations/legislation makes inaccuracy very expensive. Plus, it would open up a new market; overtake a competitor; resist a competitor. These also excite upper management.

Applying it gratifying users: are some businesses constantly approving contracts, and importing templates (or should be)? Maybe during M&A; law/consultancy firms?

Choose your customers to suit you.

People live lives. Companies create products.

Sometimes what you build becomes bigger than you. If you want to quit, and everyone else wants to keep going why not let someone else run the show?

If you started a chess club, or even a chatroom, and had no time (as the guy says, he only has one life) to be an admin, would you just close down the whole thing and kick everyone out? Maybe. If they really were so passionate they'd pick up the pieces and start their own thing. Your old group might have a way to transfer the accumulated wealth to the new group. Instead of just losing it.

I remember writing an article about this a couple years ago called the Politics of Groups:


Here is an excerpt:

If the individual - the risk is that the individual may have too much power over others who come to rely on the stream. They may suddenly stop publishing it, or cut off access to everyone, which would hurt many people. (I define hurt in terms of needs or strong expectations of people that form over time.)

Great question, imho. But indirectly it is also answered. It seemed like he spent the majority of the power into the project and the others would have joined when it was starting. It's like you have the chess club but other people only come if you are there and maybe even only if you have something special to offer.

Right but often they come for the chess. It's about the chess for them, so they don't want to have the club shut down on the whim of a single dude.

Okay, you say A, then I say "not A but B", and then you continue the discussion by saying A again?

Often times, the products we make should really be features of a larger offering. Did you guys explore building on top of your contract tech or getting acquired by a company that requires your tech? for example: 1. Marketplace of services that need contract signing between parties. 2. Project management app for SMBs or freelancers 3. Legal document authoring app that extends to contract signing.

There are prolly more ...

It sounds like most of the customers had a flawed process - or perhaps an actual process that was different from the process they felt they should have. Perhaps they were even in breach of some guidelines legal had drawn up, or even laws or statutes on acquirement.

And it sounds like the product automated a good, sound process. One that was different from the customer's actual, current process.

I don't know how one could hope to sell a new process (incidentally along with an automation framework) without massive training, and, well, consulting.

I'm a little surprised they didn't take the opportunity to pivot. Maybe none of their beta users were interested in the 100x(?) investment buying such a package would cost? It sounds like they found a different market, smaller in number of customers, larger in revenue - and chose to walk away because: software is fun, human process is hard and boring?

It's a valid choice to be sure, but it strikes me as a little odd. I thought the idealised, naive idea of a computer system being more important than the human systems it enables was more of a delusion limited to Silicon Valley, than a general problem.

I'm reminded of how model-view-controller was internally known as model-view-controller-user, and how shortening it to mvc[1] was probably a terrible mistake that obscured most of the valuable idea behind the concept (that of mapping the users mental model of domain knowledge to widgets on the screen and on to the data models used by the software).

[1] according to a talk Trygve gave, but it kind of shines through in his brief history of mvc too: https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

that's why i firmly believe you have to find the idea that you're really interested in because that's what will pull you through those 70+ hour work weeks or through those days where you're on the brink of failure wanting to fold shop. there are many ideas that are interesting and probably could be good businesses (lifestyle or startup), but can you overcome all those things not just on sheer will power, but just because that's what you enjoy spending your time on?

Or bootstrap a lifestyle business with an idea that you're really interested in and spend exactly as much time as you feel like working on it, making money and not answering to investors.

awesome, you sound like you have experience creating a lifestyle business. i'm in the midst of starting one myself.


Interesting comment in there about 'Approvals' being one of the most used feature. Why couldn't you build around that? A more generic approvals solution for any kind of contract.

Moving down market is tough. The reason why enterprise ecosystems can flourish is that consultants have a symbolic relationship with software, act as a silent sales force, drive legitimacy and solve the soft issues that make software projects fail. Creating a simple CRM system isn't that hard, but getting mass adoption AND offering a customizable product takes hand holding. Content alone doesn't hold hands, nor does (most) UX. Software that changes how people's jobs work (accounting, CRM, EHR, etc) naturally invites pushback because PEOPLE HATE CHANGE.

Maybe the next generation of UX will have change management built into the system, not just tours and tooltips. For now, the burden of software adoption is best served with donuts and somebody how cares enough to make it work for the business that is investing in it.

How then do you explain the sometime massively enthusiastic adoption of disruptive consumer software?

My understanding is that people seem to resist change in corporate environments because it is a high stakes environment where, for example, the ability to hold onto work "flow" achieved over a long period can make the difference between thriving and failing. Thus software becomes more of a political tool, not necessarily in the sense of office politics, but in the sense of being part of a strategic toolbox by which people grapple with the networks of power they participate in at work.

So corporate users are not necessarily resistant to change; they are just strategic about whether and what changes are to their advantage; if the introduction of new software can strengthen their work-related strategies, they can become its champions. I have seen this myself when I used to work for big multinational corporations.

To model software adoption in the corporate space, therefore, one might need to employ a theory of power such as Actor-Network theory (in which terms one might think of software as an actor that can be "enrolled" for various ends)

A theory of work and instrumentality, such as Activity Theory, is what most people (sometime without knowing it as such) apply to analyze work environments; but paradoxically it is usually the wrong approach to analysis. I see this failure of analysis all the time.

In a nutshell, the more instrumental and work-oriented software is, the more necessary it is to analyze it through a power-relations lens.

Quite interesting. Why couldn't you build in a reward system to using the product? Similar to how games like WOW do?

zer00eyz comment is pretty accurate. Gamification is something that came up during brainstorming, but most business users tend to view all but the most subtle approaches as distracting. We concluded we needed something that actually made their task more efficient or effective.

Gamification: it only works to a point. As he pointed out this isn't something people are SO keen on that they want or need to incentivize their employees to do it.

I don't know much about contract management so take most of what I have to say as an ignorant opinion.

I'm trying to figure out how ContractBeast's problem of continuous usage is any different than almost all the business tools out there that require human intervention (with the exception of email, and MS office suite).

It seems every investor and entrepreneur has this desire to make "crack" and not just tools. Good tools don't need to be used all the time. They don't need to provide some sort of gamification, feedback loop, or enjoyment.

As for money making good business tools don't need even need to be used by the user... in fact they really should be automated. I know this because we had some of the some problems ContractBeast did and the key was not getting the endusers involved at all. Automate and integrate so they are almost out of the loop completely (again I don't know much about CLM... maybe this isn't possible).

As far as top down selling it is almost impossible in the B2B market to do something different. Managers force users to use tools and those users use MS Office most of the time but those tools still get bought and eventually those tools do provide value (aka sales force).

500K is not a lot of time. It's six months with a small team and maybe not even that considering you need to either have time to pitch another round of funding or get to the point where you can pay the bills independently. If you don't see a path to something strong enough to get you to the next level in that amount of time, there is no choice but to walk away.

Every idea to fix it takes time to develop, and with whatever time remains you have to make progress with sales and the existing customer base. With any given product and the right team you can get there, but the only way to get the right team to commit is with a passionate belief that you will get there before you run out of money.

If you spend the time trying to build a roadmap out of whatever options you can come up with, and none of those options give confidence given time and budget constraints... well, then you've done all you can do. It's not hard to come up with a list of reasonable options to move forward with, but it is hard to come up with one that's worth committing to.

If you've grown to the point where you can man up and make the decision to walk away early, you have a good future.

"I’ve started four companies in the past with a mixture of exits and bankruptcies, so I understand that this is what startups are supposed to do, [...]."

As someone completely unfamiliar with the world of startups, this sentence baffles me. If this describes your track record, how do you even get funding? Obviously I'm not an investor, but this sentence alone is a massive red flag.

Merely knowing that something often or even usually fails is not enough information to conclude that it's a bad bet -- in order to compute that, you also need to know how much money it makes when it succeeds.

For example, if you expect something to fail 80% of the time but to gain >400% the other 20% of the time, then the bet has positive expected value.

If you've done more than a few startups - you'll have some failures.

Think of the success rate of startups as a whole. It's like 10%. So if you are at 50%, that's a reasonable bet.

It's pretty surprising to me that there was no way to shift enough of the value gain from "huge gains in efficiency" forward to keep people motivated about the product.

For example: use a chunk of the $500k as rewards to push people through the initial adoption. Then presumably the real gains would take over and they'd be happy customers.

Yes, but would that really be sustainable? Paying every single user to get them to actually use your product is generally a money-losing proposition in the long-term unless you plan to jack up your prices after you lock them in. It's also not at all clear if just offering rewards would be enough to get people to use the product in their daily contracts workflow. Switching from whatever system someone currently uses to a new one for contracts is a huge pain, so it would require a similarly huge up-front commitment. I've seen contract systems switchovers a few times at clients, and pretty much every single person in the trenches has hated it and only done it because it was forced on them from the exec team.

Having some experience dealing with the "purchasing" side of the house at large companies, I can guess part of what might have gone wrong.

Contract Beast's customers were likely exclusively these "purchasing" people, and thus, that's where the feature requests and feedback were coming from.

But, in the end, the success of the product within a customer company is often more driven by the "non purchasing" users...the actual departments that are trying to buy (or sell) something. It's not unusual for the wants/needs of these people to be completely different than the purchasing department.

I watched several attempts for contract management software fail because of this. In the end, what won out was narrowing the solution down to the biggest pain point...implementing just e-signatures. That got rid of all the manual print / sign / scan-or-fax cycle, which everyone could agree on.

The challenge with CLM is that you're constantly competing with users desire to use MS Word.

Moving everything to the cloud would be far more efficient. But the corpus of legal text captured in Word and Legal's preference for redlining email attachments is the status quo.

If we're going with the whole human centered design approach here the writing doesn't sound as though you were thorough enough in the research, analysis, and synthesis.

There should have been some guideposts here: who were the power users? what did they love? who were the huge detractors? what was their big issue? how did ContractBeast fit into the ideal world? how were people splitting their work between the old system and ContractBeast? were there network effects for the old system?

Yeah we can look at some sort of short term win and long term gain framework, but it's pretty reductionist to a) only depend on that framework and b) not be able to come up with any solutions to fulfill short term wins.

Sounds like the right move.

If you had discovered this when you were 6 months in, spent 50% of the cash and had employees would you have made the same decision? To pull the plug and return remaining capital vs trying to make it work.

I think the entrepreneur failed to assess why it had to be him to solve the market problem and give birth to the company.

Sometimes it's not necessary to assess this because you are compelled to act and you can't stop.

In this case I think had he asked this hard question sooner he would have found his heart wasn't in it. Either way dropping it was the right thing to do.

In comparison my 'why' for the thing I'm working on makes my soul burn and is a limitless well of determination.

Call it 'Conviction/Opportunity' pull.

"It would have been different if we had been debating which plan among several to implement or how to shore up specific weaknesses, but we had nothing."

I don't really understand "having nothing" -- you're either creating value or you're not. You guys spotted a real problem, but your v1 solution was meh. There were certainly multiple ways out (and not just tack on gamification), and even if some were long-shots, the uniqueness of a startup is to place those bets.

I think he just doesn't agree that there were multiple ways out. He seems to believe that they exhausted options and couldn't figure out a path.

He assumed that if he personally couldn't solve a problem in a few weeks of hard work, then nobody coudl. This is kind of naive or possibly arrogant. It also sounds weak to me, coming from academic research, in which people work very hard on problems for years, and sometimes even succeed at solving those problems (famous example: Fermat's Last Theorem).

He explicitly says in the post that he's not claiming the problem is unsolvable. If I read it right, he even thinks it is possible that he could solve it, but he doesn't want to bet a year of his life on it.

"ContractBeast did not address the problem of providing a significant, consistent and immediate benefit"

Neither does insurance but its pretty much a no brainer for most companies. Contact management isnt suppose to give instant gratification. Its supposed to provide peace of mind knowing you will not miss important dates in the FUTURE.

Hate to say it but Mr Romero seems to have given up way too early. All the smart people on HN someone will pickup the baton and run with this idea.

If you don't believe in what you're doing then I think it could have been a mistake to take the money and carry on.

If the team and investors believed in the product, perhaps you could have asked if some of the current team were willing to take it on, and make it work. You could have retained a bit of equity for the year and the hard work you put in so far without having to commit any longer yourself.

> About 35% of our users continued to use the system at least three times per week after completing registration.

OT, but curious, how is it possible to get this kind of engagement data?

Querying DB to get number of logins per week? But that doesn't mean that they're "using" the system.

Google Analytics? I'm not aware of any such GA feature

Third party analytics?


Heap Analytics and Fullstory are two popular systems (among others) for this sort of thing. They record and instrument your user sessions much more comprehensively than GA does.

Multiple ways.

Using just your database, you can store records when users complete certain actions.

Eg. When a contract is uploaded, modified, when new people are invited to collaborate over it ...

That way you simply query for user actions over a period.

I use Google Analytics to do the same thing via events. Fire events when actions take place, review the data in your dashboard.

Selling products to SMBs is hard. Most small businesses will often take the free trials but won't be willing to pay for a product if it entails a financial commitment.

I have seen a small companies use student licenses instead of paying for the more expensive commercial license in order to save every possible penny.

Why not make an open offer to anyone who thinks they can solve this problem and turn this around?

Can't you just charge them $2.99 for each contract, and go with volume?

I suspect you would get killed here. You are trying to change user behavior and as noted they don't have short term benefits. This pricing model disincentivises a company because it costs them money up front each time they try it and not showing and value.

Essentially they need to add an extra step to their routine & pay for the lack of convenience. This was likened to ecercise by the author. However, if you expect anyone without a top down authority (also mentioned) to do something that is harder & more expensive, they won't. It's why gym memberships bought on Jan 1 are rarely renewed in Feb or March

edit: so you are correct, paying for what you use is logical especially vs the value. Here it sounded like the customer has high value, but we discount it steeply for lack of immeadiacy.

Nope, His business was perfectly reasonable. He could become next Taleo/Atlassian/Slack, grow slower but dominate space. He only needed to extend offer with with self hosted version.

Great article. However given its by a ~4 time founder the logic to shut it down doesn't apply to most people reading it (first time founders).

I'm sure the fact that this was in private beta had nothing to do with the fact customers weren't using it all the time.

> I left my job in January so i could work on ContractBeast 70+ hours a week. The rest of the team kept their day jobs. That was fine. It made my final decision easier.

Reading between the lines here, I'm picking up some resentment. I think an underlying cause of the decision to walk away from ContractBeast might have been a specific subtype of founder burnout -- the kind that happens when you feel like you're pulling more than your share of the weight, and/or you feel like you're more committed to the company/project than the rest of your team is.

There's a downvoted comment at the bottom of this thread stating that the commenter would never give this guy money. That's a bit harsh, but at another point in the comment he makes a very (IMO) valid observation that burnout is at play here and the author should have taken some time off. That rings true to me.


> Weeks of brainstorming and dozens of hypotheses later, we had nothing. Not a single, plausible way of providing our users with the instant gratification their cerebella so desperately crave.

> With no clear path forward, investors ready to wire funds, and the team ready to quit their day jobs, I decided to pull the plug.

Is it just me or does this seem like there's a big hole in the plot here? The whole team spent several weeks trying to figure out how the product was going to get traction, came up with zero good ideas, and everyone's still ready to quit their jobs and work on this full-time?

Assuming this is accurate and absent further details, I can think of two non-mutually-exclusive hypotheses for how this might have actually happened:

1) "We had nothing" was really "I had nothing". Either because of a failure on the part of the author to communicate with the team, or their indifference upon hearing the author's description of the problem in question, the only person really working on solving the problem was the author. To the extent that this was the case, it would certainly have exacerbated the "I'm working way harder on this than my cofounders are" burnout described above.

2) It's also possible that the other prospective cofounders and/or early team members were aware of the headwinds facing ContractBeast and just really, really hated their day jobs and were thinking, "I honestly don't even give a shit if this company works out, I just want to go somewhere I can get paid while not having to deal with my current boss, and if it fails it's not a big deal, it's a startup, they fail all the time and I'll be able at a minimum to use the newfound flexibility in my schedule and relative seniority in the organization to make myself much more available for interviews at other companies."

Tl;dr I burned out.

Why is Paul Graham defining a word that's already well defined and understood? Go to Google and type in "define startup" and you will see that:

  startup = a newly established business
I think the reason he wants to redefine the term is so that people associate starting a business with rapid growth, which will benefit him personally. How do you achieve growth in almost all cases? By taking VC money. What happens when you take VC money? Investors expect an exit. So, even though he says you don't need to take venture funding or 'exit', he really wants people to do that, because he can make money from it.

We detached this subthread from https://news.ycombinator.com/item?id=11867810 and marked it off-topic.

I think Graham's definition aligns much better with general usage of the word than a definition that would make the new ice cream stand at the corner a startup.

Really, only on HN and other "startup forums". Anywhere else... well, do you think even an ice cream stand is immediately a viable, profitable business? Usually not. The space between "having a registered company" and "actually in the black and stable" is a startup.

I would still say that, to most people, a startup implies more than just a newly started business. I have never seen or heard someone who has just started a small brick and mortar business (without grandiose expansion plans) refer to it as a startup.

That said, I'm not a native english speaker and I don't live in US - maybe it's more common than I think.

You're correct. We'd just call them small businesses.

Though I have seen some small businesses working in technology refer to themselves as startups without really understanding the definition (or because they're trying to sound "sexy" to recruit developers).

You are too old. Its youngster hipster speak for running your own small business these days. I have heard a few friends referring to their business as a startups.

What about bootstrapped startups? They have to be in the black very quickly, if not from day 1. Do they count as startups?

Really, we've got four different terms we're trying to delineate.

"Exponential growth business" vs. "Incremental growth business".


"Unstable business with total expenses exceeding profits" vs. "Stable business with total expenses below profits"

All 4 permutations are valid. I personally like putting the startup vs. small business terms on the first category, which makes for the 4 pairings ["stable startup", "unstable startup", "stable small business", "unstable small business"]. I think this helps prevent the confusion that makes fruit stands think about E rounds.

Small nit: you mean to use "income" or "revenue" where you use "profits" above.

yeah, got a little confused there.

It seems to me that "startup" has connotations that are missing from the Google definition, and if Paul Graham isn't correct he's a lot closer to it.

ContractBeast would have accumulated lots of data that would be compelling for its users. The only problem is that you cannot hand out that data directly: How much did someone else pay for the same contract? What conditions did he get? If you find a way to effectively use this information without actually revealing it, you would have found the compelling feature that you were looking for. ContractBeast would have become the go-to place to check if your contract actually makes sense.

it was a bad idea #savedyouaclick

It seems like the marketing was all wrong. If you're selling to big business, you need a big business sales process. If you can't afford that, you're just pissing in the wind. He was focused on product when he should have been focusing on his sales and on-boarding.

Patrick McKenzie has demonstrated that you can do high-touch corporate sales as a small organization or even as a single person. He just needed to figure out how.

After this, I'd never give this guy time or money and I doubt anyone else will either. No matter how shitty you feel about your start-up, if you have a willing team and cash, you should see it through. Being an entrepreneur isn't always about having all of the answers. It's very often about not knowing the answers and figuring things out. Especially if you have a team and cash flow and investors.

I think this guy needed to take a day off or seven and get his head back on straight. I'm nearly positive every entrepreneur goes through the "doubt" process many times in a given start-up.

It's the person that figures out how to renew themselves that ends up succeeding.

> The rest of the team kept their day jobs.

> The team was excited. Our potential investors were excited.

He didn't really have a team and he didn't really have investors. He took a personal risk and found it wasn't working. He shut it down before it got expensive for people other than himself. I applaud this.

People, especially around here, need to understand failure is the norm. This person failed fast, well. Nice work. On to the next thing.

This goes to my core belief that "failing fast" is bad for entrepreneurship. It is far more rare for an initial idea to succeed than one that morphs out of original ideas. Even Facebook started out as something other than what it is now.

I have nothing against accepting failure in an idea. My first start-up failed and I had to let it go. It was really fucking hard to do that. But I tried to pivot twice before finally letting it go and I worked at it for a number of years.

The people that want us to fail fast don't have entrepreneurs best interests at heart. They're looking for quick wins and the more starts and fails they get, the better _their_ odds of something "popping".

But there's something to be said for perseverance.

I won't argue that there shouldn't be a balance, and maybe I was too hard on the OP, but it sounded to me like he needed to step away and think about it, not just let it go.

But I guess we have to defer to his judgment since it was his idea.

I just really don't like fail fast mentality.

Opposite to me, finding a group of guys willing to take your money, and work their brains out until it runs out isn't hard to find. Finding a guy who will take that money only if he thinks he can do something productive with it, is much more valuable. I know I can feel pretty confident that if he's taking my money, he's optimistic it'll turn into something. I gotta say, I respect his move.

Isn't it better to bow out before taking on more money and FT employees when he knew he didn't want to commit?

When your heart isn't in something, there's no way to "get your head back on straight".

He did the right thing.

To me it looks like you haven't seen that he understands all that what you say but figured despite all that there was an exceptional situation that required him to do something unorthodox. And that's also a good thing for an entrepreneur, right? Making a decisions others wouldn't have because one believes one has better insight into the situation.

It's only a matter of time before this kind of thinking results in founder suicide. I've read multiple cases where investors, including Y Combinator, forced founders to pivot, which caused serious mental distress to the founders. If the idea won't work, drop it, and drop the founders too, until their next project can be properly assessed. Dropping a project doesn't mean the founders are bad founders or that they are great founders - it simply means that they realised the limitations of the project. Investors should keep the founders in mind for their next project, but giving them cash and forcing them to pivot is a sure way to disaster. Ideas need time to develop. Tim should be commended for realizing that his product would not work, and dropping it before it caused his team and the investors even more stress. I consider his post a sign of maturity and look forward to hearing about his next project.

> I've read multiple cases where investors, including Y Combinator, forced founders to pivot

I don't think you should sling this kind of thing around so lightly. It's trivial to post charges like this on the internet and have many people just believe them. But this is a serious thing to say right after you've invoked the idea of suicide, and doesn't remotely resemble anything I've observed at YC. In my observation, YC partners don't "force founders" to do anything; they couldn't anyhow, and they don't think that way in the first place.

Here's one Y Combinator founder who spoke out about the continual push to pivot. https://backchannel.com/how-i-f-ed-up-in-ycombinator-35a19e7...

>The last few weeks of the program are a bit of a blur. My morale plummeted, and my stress skyrocketed. I dreaded going to the weekly dinners, where I would have to talk to my cohort and confirm that no, we hadn’t found an idea yet and yes, we were still super excited about our “company.” I did little else but eat, code and sleep. I felt like everyone else was ready to raise millions, while we were desperately trying to find a product.

>Postponing Demo Day was a no-brainer. We didn’t have an idea we believed in, and although we could have cobbled one together and raised some seed funding, we didn’t want to do that. I didn’t want to do that, in part because it seemed disingenuous. But primarily it was because taking half a million dollars of other people’s money would have moved my stress level from unhealthy to crippling.

>But skipping Demo Day didn’t fix our lack of conviction. The rapid-fire pivoting continued. Around this time, I started coming to terms with the fact that I was seriously unhappy. For as long as I’ve been interested in startups, I have never wanted to start a company simply for the sake of starting a company. Yet doing things “for the sake of starting a company” was where I found myself, as I scrambled for a plausible idea.I don’t know if this is true for other people, but as a flailing founder I desperately wanted to believe in the startup myth—that success was just over the next ridge, that if we waited a bit longer, or had a slightly better idea, we would suddenly be riding a rocket ship. I hated doubting myself, but I’ve never been good at blind faith. So I decided to leave.

Really hard to read the article and conclude that "YC forced them to pivot". Sounds like things weren't working and YC was honest with them.

From the same article:

> We went back to PG, and he told us to stop worrying about Demo Day. With the right idea, we’d be working on the company for the next five-plus years. It was foolish to sacrifice the quality of the company to optimize for the next five weeks."

Seems like a good long-term view and very reasonable way to look at things... definitely not crazy "pivot-right-now-or-die" pressure.

...except every 5 weeks is do-or-die with starving startups. Sounds like PG had some inside info on whether they would get funding. Otherwise that would have been the most foolish advice.

The key point is "With the right idea"

They were told their original idea wouldn't work, and they were put in a highly stressful situation of having to come up with a new idea under a short deadline, with high expectations. It doesn't matter if PG was nice about it, there was an enormous amount of pressure put on them to do something to be worthy of their position, pushed along with the implied message that that's what founders do - they can make magic from thin air, instantly. The cult of the founder. It's no surprise that this made him stressed and unhappy. I wonder how many people have been through the same situation, with YC and beyond, but will not speak out.

Agreed that there's a ton of pressure and that can lead to unhappiness, stress, or worse. Doing startups isn't for everyone. Doing YC isn't for everyone. Doing YC with an idea that isn't working must be extremely unpleasant.

But pressure is the nature of startups whether you're in YC or not. And while YC knows a lot about good, bad, ugly startups and how to potentially fix things, it's fundamentally the founders' company and they have to make the decisions and execute. I don't think that's "founder worship" - it's just reality. Default state of the company is "dead". Good ideas and good execution are the only things that change that. It's not YC's company. They're there to help.

Anyways, we likely agree that the mental health downside of doing startups is poorly understood or appreciated so maybe let's leave it at that.

I read that story and the author's own comments on HN, and they do not support the argument that YC "forced" them to pivot. If anything, they barely knew what they were in YC for in the first place.

Actually, that's my point. They were accepted and told that their product was no good straight away, thus forcing them to pivot. So why were they accepted with a poor product, when other applicants who had stronger ideas were turned away?

A selection process that supposedly values the skills of the people over the combination of skills and product will lead to people like this guy not knowing why they were selected, and not being able to handle pivoting. It's something YC should stop doing before it causes real damage.

You keep saying they were forced to pivot as if you might convince by sheer repetition. They made the choice. They surely didn't have to. For that matter, if they wanted to drop out, they could have.

Your argument seems tendentious.

tendentious |tɛnˈdɛnʃəs|


expressing or intending to promote a particular cause or point of view, especially a controversial one: a tendentious reading of history.

Applications are open for YC Winter 2024

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact