Building a Product instead of a Program
4 lessons I learned about this vital difference.
As a software engineer, I’ve always felt that a key part of my job is to keep pushing the boundaries of the technology that I work on. Perhaps it’s because I love new challenges but I’ve definitely also seen this passion in many other developers. There’s just something fulfilling about always living life on the bleeding edge.
But recently, I’ve really had to challenge my approach to development. Working on a product as both an engineer as well as a co-founder has made it difficult to look at the product as just a program. Our regular conversations with users & professionals in the industry have added many more complex layers on top of the program that simply cannot be captured by code alone.
This journey has led me to internalize the idea that a product should not just be a utility, it should be an experience. Consequently, the most exciting part about working on our product is no longer strictly the technological innovation, but actually the value that it brings to users.
A product should not just be a utility, it should be an experience.
This was definitely not an overnight experience. It came with the usual making mistakes, breaking things, & wasting time that most learning experiences come with. Below, I’ve tried to sum up some of the biggest points that I’ve learned over the last little bit.
Stay away from new technologies
As a developer moving from a stable day job to working on your own startup, I reached for the shiny new tools right away. I’ve been in love with JavaScript for about 9 years now but recently I’ve begun to have a love affair with Go. So as soon as it came to the choice of technology stack for my new product, I immediately jumped into building it in Go from the ground up.
And it was great… for the first few days. I managed to hit our first product milestone faster than we had planned. But as soon as it came to a more complex problem, I realized I really wasn’t as comfortable with the nuances of the language as I am in JS. Specifically, going from a multi-process to a multi-threaded programming model threw me off for test sharding (if you don’t know what I’m talking about and want to know, or if you’ve already solved this issue in Go and want to enlighten me — I’m @karimsanet on twitter).
After a couple of days of mindless debugging, I ended up having to rewrite everything into JS – at which point I was able to breeze past the problem I was having with Go within a few hours without even realizing it.
This experience really made me realize that it’s always better to rely on what you know rather than learning something, especially when velocity is an issue.
Not everyone is a power user
This is another misconception that I had when I began working on our startup. I love customizing my products to fit my workflows and really to use them to their fullest. As such, I often go looking for the customization options in a product before I even consider making a purchase. I would say this makes me a power user for these products.
That being said, I am not a universal power user. There are many applications that I expect simplicity from. For instance, as I write my article on Medium right now, I’m enjoying the immersive writing experience that their editor has to offer. It is particularly important to me that there is no fancy WYSIWYG editor or advertisements trying to distract me from my goal.
This is a really important detail. Depending on your product & your target customer segment, you will need to ponder over whether your users truly want customizations. Creating a future proof product seems like a great idea, but sometimes we tend to optimize our software and spend too long planning for a future that never comes.
Sometimes we tend to optimize our software and spend too long planning for a future that never comes.
Future Proof: trying to anticipate your users’ needs
The only way you can truly avoid this hurdle is through solid customer validation. To learn more about customer validation & its relationship to product design, check out our article on the subject.
Learn what customizations are genuinely important to your user, and don’t build unnecessary “future proof” designs for future features that may never exist.
Minimize dev processes
Processes can be great. They help your team stick to tasks that work towards a common goal and they really help you organize prioritizes and deadlines. But when you’re an infant startup with a 1–3 person team, you should avoid processes like the plague.
The problem with process is that it inevitably slows down development. This is a good thing when your scale increases because it helps to slow down the unfocused development and empower focused development. But when your team is relatively small and your only goal is to get to market, you don’t want to be worrying about details like “are we going to use Kanban or Scrum”. You want to focus on time & efforts on getting work done.
This doesn’t mean that you shouldn’t plan your work, but you don’t need to enforce human-powered processes like QA that will stop you from moving onto the next feature.
As you stumble to find your product-market fit, the bugs in your application are not too important.
It also helps to understand the concept of resilience a bit better — a topic that I’ve spoken about previously about at OttawaJS. Your user’s perspective of failure is not the same as yours.
Organize your debt, don’t solve it
As you develop really fast, you’ll be forced to make tough decisions. The engineer within you will want nothing more than to create a highly scalable piece of software & solve all your scaling issues today. But the tough realization is that not all issues need to be solved today.
Sometimes we’ll tell ourselves that it is acceptable since it’ll only take 5 mins of development time.
But your 5 mins of development time can lead to hours of testing time & open the door for new types of bugs.
It’s important to recognize that it won’t ever be possible to fix every last thing, and recognizing this will help you decide what is and isn’t worth your time right now.
As you do this, it’s fairly important to note the decisions that you make. At NGD, I do this by adding descriptive TODO comments that:
- mention an open JIRA issue
- explain the decision and the possible issue with it
- explain when the issue would actually become a business problem.
This helps me keep track of the debt I collect and also note when it’ll actually be important to address.
Conclusion
I hope these tidbits from my journey are meaningful to you! If you’re going through a similar journey, I’d love to hear about it – you can reach out to me via karim@nxtgendevs.com.
