Let Your Customers See Your Imperfect Product
By: Ryan Kwan
Tags: JavaScript, Programming, Software Development, Technology, Software Engineering

My first piece of work was also a new product for the company and the idea of a minimal viable product was blurry to me. All I knew was that there were business requirements for the product and I had a timeframe to release it.

The product was a supplementary tool, designed to go alongside my company’s main offering. It needed to allow customers to easily move the contents of an email into our software.

At that point, I thought, this is a small project and it isn’t going to take so long. With that in mind, I drafted up the features I wanted to implement, and then drew up some wireframes.

As soon as I started development, I knew I was wrong. There’s always some sort of blocker in your way. Immediately I was stuck on the setup of the project, and I hadn’t realised that I would be building it using TypeScript — something I haven’t used before at the time.

A month quickly went by, and I have only built very basic features. Or so I thought.

You’ll never be satisfied, however it looks.

In the past, I have picked a piece of software, a utility company or even a bank because of a nice UI and I really couldn’t let my first product slide.

As my product was supposed to be used from inside of Office 365 or Outlook, my first iteration of design mimicked the design languages of Microsoft products at the time.

Remember Windows Phone? Those menus with oversized text across the top as tabs, right aligned titles, and Segoe UI font family. I designed the entire UI based around Fabric UI and it felt unmistakably Microsoft.

One iteration led to another. I didn’t like the oversized text tabs, so I quickly got rid of it. I wanted to implement a small navigation bar. I wanted to do a settings menu.

The more I researched, the more I wanted to do.

No customer ever sees your code.

Remember what I said about the company’s codebase? I would never let myself do that.

You build components, then your components get bulky. You will then separate the code out into new files.

Reality strikes quickly. You have a folder structure, then because of how the structure of your components change, your files are now a mess.

Many developers go through this phase. I feel like it’s a part of learning, or almost a right of passage. But sometimes, you just have to understand — If it works, it works.

If you never ship your product, who cares if it has everything?

It wasn’t until my team lead reminding me that I realised that what I thought was very basic functionality was already more than sufficient for solving the original problem.

I realised my planned features have already gone far beyond what the product needs to do. It was time to wrap it up.

This is especially relevant if it’s a new subset of an existing product or a supplementary product as the benefits of a hard launch — i.e.publicity or quick revenue is less applicable.

It was probably more beneficial for both myself and the customer to release the product, so they can actually have what they’ve been asking for, and for them to tell me what else they needed before moving on.

Don’t be afraid to just ship if you’re already solving the core problem. Your customers will be the judge.