Building the Beast

Our target users responded positively to the mock-ups, and many excitedly asked when they could start using it. I was on the right track. I spent the next few months working evenings and weekends developing an MVP and getting feedback on features as they were implemented.

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.

We started private beta in early March, and things looked solid. About 35% of our users continued to use the system at least three times per week after completing registration. The UI needed work, but our users raved about how ContractBeast would save them time and worry in the future.

The team was excited. Our potential investors were excited.

But something was wrong. It seemed trivial at first, but it bothered me. Despite glowing praise, our users were only using ContractBeast to create a small percentage of their total new contracts.

I spent the next two weeks visiting our beta users, looking over their shoulders as they worked, and listening to them explain how they planned on using the product. Pressing them directly on why they were not using ContractBeast to create all their contracts resulted in a lot of feature requests.

Now, talking with customers about features is tricky. Often you receive solid and useful ideas. Occasionally a customer will provide an insight that will change the way you look at your product. But most of the time, customers don’t really want the the features they are asking for. At least not very badly.

When users are unhappy but can’t explain exactly why, they often express that dissatisfaction as a series of tangential, trivial feature requests. We received a lot of ideas like integrating alerts with various messaging platforms, using AI to analyze contract content, and building more sophisticated search features. These aren’t necessarily bad ideas, but they had nothing to do with why they were not using ContractBeast more extensively.

I might write another article on how to tell these tangential feature requests from useful feature requests. Your customers mean well, but implementing these kinds of features will not make your users any happier in the short term. In any event, I was overwhelmingly getting these kinds of tangential, trivial feature requests.

I couldn’t sleep. My users told me they loved the product, and that they planned to use it extensively. But weren’t really using it much, and I had no idea why.

Sipping decaf coffee at 5:00 AM on a cool May morning, I was re-reading forty pages of notes, user feedback, and profanity. The fatal flaw jumped out at me. ContractBeast provided huge gains in accuracy and efficiency, but those gains came after months of use. It didn’t provide a significant immediate benefit.

I was fighting human nature and losing.

Everyone swears they will eat right and exercise, but most don’t. Everyone agrees they need to spend less to be financially secure later, but most won’t. Our users were telling us they would use ContractBeast to achieve those long-term benefits, but most weren’t.

When I looked at the contracts the users were creating, I found most of them were ones in which a particular feature provided a clear and immediate benefit. Usually involving contract review and approval.

Human nature sucks.