Why You Should Stop Spending so Much Time on Your Code

The beginning of a new venture is a very exciting time for an entrepreneur. They are envisioning a cool product, perfect product-market fit, and widespread adoption and success. At this stage, most founders tend to roll up their sleeves and dive into coding their cool product to get to market as soon as possible. However, in most cases that is the most inefficient step.

It was the beginning of the spring semester of my junior year in college and after spending my previous summer at an entrepreneurship summer school and working with a great startup in Menlo Park, I knew it was time for me to channel my passion for problem solving into my own venture.

One of my classes in the spring was Marketing, where I was learning about consumer psychology, marketing methods, and the most optimal channels. While learning about Marketing ROI, it struck me like lightening — if the big companies can’t tell how effective their marketing efforts are, what about the 28 million small businesses?

Armed with a problem and an idea about how to solve it, I recruited two of my friends and started building a ‘unique’ micro-influencer platform for small businesses. We coded non-stop. Days turned into weeks, and weeks into months until we finally had a demo-able product. We were ecstatic!

We were very proud of our product. It had taken longer than we expected, but it looked great and had some really cool features. We presented it in our marketing class and everyone loved it and thought it was genius. In our minds, we were already imagining our mar-tech empire.

The fall of an ‘empire’

It was time for our first litmus test — actual customers. I quickly spent some time learning about sales techniques and set out with a sales deck and a product demo to some nearby local businesses. Nervous, yet optimistic. However, in our very first meeting, I knew there was something wrong.

My first meeting lasted 25 minutes. Like a good salesman, I spent some time learning about their marketing pain points to confirm my hypothesis that their existing marketing processes were inadequate. Then, I proudly presented my product and explained its benefits. However, in contrast to the wide-eyed admiration and excitement I was expecting, I was greeted with an unsure glance and expressions of confusion.

Taken aback, I kept blabbering and explaining the product, highlighting benefits, and hyping up its potential impact but to no avail. The meeting ended with a ‘I might think about it’ and I was on my way wondering what went wrong.

Weeks went by, and every meeting ended the same way — ‘I will call you and let you know’, ‘Maybe soon’, ‘Interesting, let me think about it’ — but not even one customer actually responded. Despite constant follow-ups, we were not making any progress and customers were starting to ignore us.

We were starting to resent our customers.

We had spent so much time building the product that we had convinced ourselves that it works. But when customers were ignoring us, instead of blaming the product, we blamed the customers.

Blame Thy Product

Finally, one day, I took a small business owner from my network out for coffee to show him the app. I told him to be perfectly honest with his feedback.

He said, ‘Looks great, but how do I use it?’

I was confused. I thought the app was obvious and easy to use. Plus, he said he did not understand how our app would integrate with their existing marketing efforts. I realized that it did not. I was walking in to businesses asking them to drop all of their existing marketing efforts to switch to an app which did not even make sense to them. Our product was a failure, but only because we spent the majority of our time coding the product and then resenting our customers for not liking it.

Our process was idea → product → pricing → customer. It should have been idea → customer → product → customer → pricing → customer

By actively involving the customer in every step of the iteration process, you de-risk the product and make its long term implementation and iteration exponentially faster. Once we figured it out, our resentment gave way to relief. We dodged a bullet. If we had continued on this path with a false sense about the superiority and effectiveness of our product, it would have been even more depressing and upsetting to learn otherwise. The more time you spend building the product, the harder it is to accept its shortcomings.

Move fast and break things.

Mark Zuckerberg

Round 2 — SimplyStow

Soon after shutting down the influencer marketing platform and walking away from it with newfound wisdom, I had the opportunity to put it to the test.

When we started SimplyStow to match people with extra space to people looking for storage, we didn’t even begin coding anything for the first month. Rather, our ‘MVP’ was a GroupMe where we made connections and matched users.

After spending time observing interactions on GroupMe, learning about the customers and their needs and how they conduct their transactions (knowledge and money), we finally started to code. But instead of coding the app, we conducted weekly feature sprints where we built a feature and tested it with the customer.

The customer feedback was so valuable and insightful that it cut down our development time by 70%, making iterations faster and better.

Our customers were delighted with our alpha, even though it was ugly, because it solved a major problem in a way that made sense. Even with a partially functioning product, we were able to help two customers store their stuff.

I know it gets harder to go through this process when you have hundreds of customers. However, I think the ideal way is to create a ‘Customer Board’ comprised of representative customers from each of your customer segments to constantly test features and make sure the product you envision is the product customers need.

As a result, we went from idea to product in a month because we made our customers play an active role in our development process.

We learnt that our customers don’t care about our code, but about how it makes them feel.

Once you realize that, you learn to spend more time on the customer experience and less time on your code. We don’t know how many customers we will reach by the end of our journey, but we are now confident of creating unique value for the ones we do reach. And this time, our customers will vouch for us.

Paraj’s Note: What has been your biggest takeaway about the early product iteration process? Do you think customers care about the product’s underlying code? Let me know your thoughts and feedback in the comments below. If you liked the article, share it with one early-stage startup founder in your network who you want to see succeed. If you hated it, share it with a a rival founder.

Paraj Mathur is the co-founder of SimplyStow and a senior at Franklin & Marshall College. Follow along with him on Twitter and through his podcast — SimplyStartup.