Any software engineer knows that their programs never work the first time; even if they do, our trust issues come out and our first thought is “I’m not THAT good…”
There are either corner cases that you think will never happen, and then they do, or something just doesn’t work and you spend hours tracking down the problem with “console.log”, “logging.debug”, or my personal favorite “Serial.log(“Hello1”).
People who code often look at finding bugs as a notion of defeat and ridicule. I often hear a non-tech lead cry on and on about how a bug needs to be fixed and how the program needs to be perfect. That doesn’t really help developers because while we can strive for perfection, there will always be bugs. Even Google, the company with some of the best engineers in the world, has plenty of bugs in their programs. So instead of fixing every bug and optimizing everything, I had to assign weights to each bug.
I decided the only way for me to provide a non-biased opinion on what needed to be fixed was to have the customer decide (I get distracted with bugs way too often). My first approach was to add a small link to an open github repository on the left-hand side. People could post bugs and provide feedback. Sounds great, right?
But not a single issue had been posted in over two months. Even though the people using it at this time were mainly developers, it’s rare that people want to help a for-profit company. So I had to figure out a better way to obtain feedback.
Instead of going the developer software route, I just asked if I could watch people use the platform and take notes as they printed something.
Instantly, I got feedback on things I needed to improve on, whether it was UI bugs or actual interface issues that were previously unreported. People who saw how much I cared about their experience would then rush over to me whenever they found a bug. My github issues page started filling up and I again had things I could fix, this time with a better understanding of what was important.
As the bugs slowly got ironed out, new users were getting started with printing faster and faster. The best day was when the Operations Manager started using the platform and said, “Damn, this is so addicting” as she watched the live stream of the print head slowly moving side to side. I thought she was just being nice as I was walking by, but soon the residents of the Innovation Labs who knew nothing about 3D Printing were starting to print. Pandas, VR Headsets, and cookie cutters were churning out. They were so excited, they were constantly giving me feedback, suddenly interested in the success of MakerFleet. I improved and improved and improved, working tirelessly to remove the bugs to make the whole thing work like a well-oiled machine.
I’m addicted to adding new features. It’s exciting to hear your customers give you passionate feedback about what MakerFleet could do and in your brain, you’re just thinking “I could code that in a day! That’s so simple!”
It’s so easy to get distracted by new features and what’s “cool” that it’s hard to focus on what’s necessary for the company to succeed. This was probably the hardest thing to do as a solo founder: find what features needed to be added and what features were supplementary.
This started with the personalize feature, which I personally thought was extremely important. The ability to add personal and emotional value to existing models with an easy to use interface. I stayed up dreaming about how awesome that would be and it would only take me a day to make!
It actually took me a week, and it still wasn’t done very well. Even when it was done, I was angry that I spent so much time building it. I hadn’t even launched so there was no one to use the feature. To some, a week isn’t that long, but to me, a week of spending time on non-critical aspects of the company meant that we weren’t moving towards a goal: Launching.
So I again outlined everything I needed to do to launch: only write features that were explicitly outlined by people who would pay for it. We had to deprioritize features suggested by people who wouldn’t pay MakerFleet. It was just the economics of the company: build what our customers could pay for, not necessarily what was “nice to have”.
But what did our customers want? Who even were our paying customers and what did they like?