Hi. Tim here.<p>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.<p>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.<p>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.<p>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.<p>4) Whats going to happen to the code and to Tim? No decisions yet. I'm open to suggestions on both counts.
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.<p>Sorry man. Good call not to waste a year of your life.
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: <a href="https://medium.com/startup-study-group/my-two-years-as-an-anthropologist-on-the-photoshop-team-e700acb7d3d5#.t6m5wue0c" rel="nofollow">https://medium.com/startup-study-group/my-two-years-as-an-an...</a><p>As far as tools go, ethnography can be very powerful in the right hands.
"When users are unhappy but can’t explain exactly why, they often express that dissatisfaction as a series of tangential, trivial feature requests."<p>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.<p>Sometimes it feels like the people giving feedback are just too eager to please you with positive feedback.
"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."<p>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.
I have to say, I don't agree with this part at all:<p>"But most of the time, customers don’t really want the the features they are asking for. At least not very badly."<p>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."<p>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.
This story has a ridiculous amount of integrity. You did what was right, even when convention went the other way.<p>Future investor reaction to it will tell us what they think of <i>actually</i> 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.<p>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.<p>It's a long slow burn and mightn't work.
People live lives. Companies create products.<p>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?<p>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.<p>I remember writing an article about this a couple years ago called <i>the Politics of Groups:</i><p><a href="http://magarshak.com/blog/?p=135" rel="nofollow">http://magarshak.com/blog/?p=135</a><p>Here is an excerpt:<p><i>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.)</i>
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.<p>There are prolly more ...
It sounds like most of the customers had a flawed process - or perhaps an <i>actual</i> process that was different from the process they felt they <i>should</i> have. Perhaps they were even in breach of some guidelines legal had drawn up, or even laws or statutes on acquirement.<p>And it sounds like the product automated a good, sound process. One that was different from the customer's actual, current process.<p>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.<p>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?<p>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.<p>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).<p>[1] according to a talk Trygve gave, but it kind of shines through in his brief history of mvc too: <a href="https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html" rel="nofollow">https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html</a>
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?
Tim,<p>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.<p>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.
I don't know much about contract management so take most of what I have to say as an ignorant opinion.<p>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).<p>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.<p>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).<p>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.<p>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.<p>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.<p>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, [...]."<p>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.
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.<p>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.
Having some experience dealing with the "purchasing" side of the house at large companies, I can guess part of what might have gone wrong.<p>Contract Beast's customers were likely exclusively these "purchasing" people, and thus, that's where the feature requests and feedback were coming from.<p>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.<p>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.<p>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.<p>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?<p>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.<p>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.<p>Sometimes it's not necessary to assess this because you are compelled to act and you can't stop.<p>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.<p>In comparison my 'why' for the thing I'm working on makes my soul burn and is a limitless well of determination.<p>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."<p>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.
"ContractBeast did not address the problem of providing a significant, consistent and immediate benefit"<p>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.<p>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.<p>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.<p>OT, but curious, how is it possible to get this kind of engagement data?<p>Querying DB to get number of logins per week? But that doesn't mean that they're "using" the system.<p>Google Analytics? I'm not aware of any such GA feature<p>Third party analytics?<p>Surveys?
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.<p>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.
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.
> 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.<p>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.<p>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.<p>Also,<p>> 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.<p>> 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.<p>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?<p>Assuming this is accurate and absent further details, I can think of two non-mutually-exclusive hypotheses for how this might have actually happened:<p>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.<p>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."
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:<p><pre><code> startup = a newly established business
</code></pre>
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.
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 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.<p>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.<p>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.<p>It's the person that figures out how to renew themselves that ends up succeeding.