I sat at a Starbucks cross-legged with my laptop on my lap. I’d gone out to try and find the peace required to focus on the job application I was completing as a front-end product developer.
The task was simple: Create a demo app that connects to an API (Foursquare) and shows the results.
As I sat there putting the finishing touches on the demo (you can actually still see it here) I had a realization…
I had achieved one of my biggest goals as a programmer:
Be able to build a product. A real digital product.
Why was this a goal of mine? Because I wanted insight.
I wanted the ability to understand and empathize with every department of a company.
Because when we work for an established company, many decisions are made for us by different departments or even the programmers before us, meaning we’re often not exposed to the bigger picture.
Marketing decisions are made by marketing, product decisions by product, for instance. But as a programmer, we are the beating heart of it all. Knowing and being able to empathize with these different departments and people can make us better as programmers—something most programmers don’t take the time to do.
I knew building a product would help me with my career as a programmer; and who knows,if it works and grows, maybe it could become a second source of income or even my full-time job.
It was this moment in Starbucks, creating a demo app, that started a long and winding journey into a fascination with building my own digital products and subsequently learning everything about them.
Since building several digital products, I’ve learned a lot about myself—but most importantly I’ve learned what it really takes to get a product out of the door.
I’m still learning and I’m still building—I’m not done yet. But one of my values is to always share the process. To lift the curtain and share what I’m working on. In doing so, I can bring insight to and inspire others to start creating products. If they feel as I felt a burning desire to create a product—then hopefully these stories can spur them to make a start.
The thought of building a digital product is something that has probably passed through the minds of many programmers. But be warned: before you jump right in and start building a product, there are four questions you really ought to ask yourself first to know if building a product is right for you.
Let’s take a look.
Projects Vs Products
Before we dive into the questions, I want to pause. It’s important for me to stress that this post is about products, not projects.
But why the distinction?
A project implies an end date, or something you’re only mildly committed to (like the term “side project”). Projects might look like building a small plugin, learning a new technology with a starter framework, or writing some open-source code.
On the other hand, a product is ongoing. It’s something you craft to help someone with a problem. You assess their needs and desires and deliver a solution.
You might not develop your product every single day, or even every single year. But the idea behind a product is that users are actively engaging with it. A product doesn’t have an end date; instead it keeps growing, evolving, and improving.
A project is more of a puzzle piece, not a full puzzle. You will need to start many projects, such as learning a new technology, in order to take your product further.
And that’s what this post is about: products, not projects.
Question 1: Why build a product?
Before embarking on any journey, we should ask the question: why?
Friedrich Nietzsche put it aptly: “He who has a ‘why’ to live can bear almost any ‘how.’”
Asking “why” helps us understand our own motivations. Poor motivations will ensure that our product flops, whereas strong motivations ensure we can “bear any ‘how.’”
If you’re considering building a product, you should ask yourself:
- What do I want out of this?
- What will this product bring to the world?
- What is its purpose?
- Why do I want to create it?
Now isn’t the time to consider the market implications of your product, such as whether it will be received well or not. The question of market adoption is secondary to the topic of “why.”
But why is that?
Because if we don’t have a compelling reason to build the product in the first place, it won’t matter how good the idea is.
Knowing why on its own isn’t enough. We must also prioritize our reasons. When we do this, it allows us to make better decisions as we know what the primary focus of the product is to us.
Some reasons for creating a product could be:
- For fun: you simply want to code
- To learn: you want to learn a new technology
- For profit: you want to build a functioning product or service
Ryan Holiday offers some words of warning about prioritizing goals in his book Perennial Seller: The Art of Making and Marketing Work that Lasts:
“Nothing has sunk more creators and caused more unhappiness than this: our inherently human tendency to pursue a strategy aimed at accomplishing one goal while simultaneously expecting to achieve other goals entirely unrelated.”
If you’re building a product to learn to code but get caught up in wanting to also make it profitable, you could end up taking yourself further away from your original goal rather than towards it. Knowing your intention keeps you on track.
Question 2: Do you need a team?
Okay, so you have a “why” for your product. Maybe your reason is to help with your personal brand, to learn, or to create a new source of income.
The next question to ask is whether or not you’ll need a team.
The question of a team isn’t something to take lightly. Whether you’ll need a team could be make-or-break as it was for me (more on this later).
If your goal is to learn, you might want to build this product all on your own. But, if the product’s success and speed to market is more important, you might want to consider handing over some responsibilities to a team, or at least a partner.
For the first product I created, I didn’t think about a team but instead started creating it on my own. It didn’t go entirely to plan.
The product was called The Lifting Academy.
I was a powerlifter and weightlifter at the time, and this product was born out of my frustrations.
Whenever I was asked to mail a check to sign up for another competition, I noticed just how far behind the industry was compared to others. When I thought about the experiences I had had with other companies, sending checks in the post seemed archaic. I didn’t even have a checkbook!
I pictured a different future, one that was more slick and seamless.
Finding coaches at the time meant asking around on Facebook groups for recommendations;I pictured it as simple as searching for a restaurant on TripAdvisor.
Applying for competitions meant asking around and calling people. When you finally found one, you had to understand the rules and apply to the federation—and that’s not even getting to the equipment yet. I saw no reason why finding a competition should be any different from the great experience you get with websites like meetup.com or eventbrite.
The vision of The Lifting Academy was simple: To enable more people to discover and get involved with powerlifting and weightlifting.
But the difficulty came around having such a large vision. The product was far bigger than me. I needed help, as I had no one to bounce ideas off of. But, despite all my hard work and struggling, I couldn’t find someone to come on board and help me out.
Eventually, I stopped all work on the product completely.
The decision to shut down The Lifting Academy wasn’t because it totally failed; in fact, it showed great promise (the need is still unmet today). It was the absence of a strong, motivated team that prevented me from continuing with the product.
Instead, I opted to go headfirst with a different product I was building at the same time: Hacktopia.
Hacktopia had a different birth from The Lifting Academy. Rather than coming in with a product and then seeking a team, Hacktopia was born from a core team sharing a common vision.
These were two very different inceptions.
Depending on your ideas, you might want to start with one or the other. It all depends on you, your skills, and what you’re trying to achieve with the product.
Question 3: Are you willing to make sacrifices?
Building a product is time consuming. Elon Musk has compared being an entrepreneur to “eating glass and staring into the abyss of death.” I don’t think he’s far wrong.
It’s very easy to dive straight in and start building a product without first considering the sheer magnitude of what we’re embarking on.
If you choose to build your product while you’re working a full-time job, this might not leave great amounts of time for other areas of your life. In pursuit of your goal, something might have to give, and that’s a situation we need to be mentally prepared for.
When I was in the middle of building The Lifting Academy, I remember having a conversation with a colleague. He speculated,
“I have friends who have built projects and they’ve spent five years on something that didn’t work. I don’t know if I could do that.”
What he was saying is that he didn’t know if he could make the sacrifices necessary to be successful with his product. He correctly recognized that the pursuit of one endeavour likely comes with the cost of another.
But I knew that, to him, he was talking about a huge cost—the cost of many years of his life. Years that could be better spent doing something else. Having beers with his friends, or travelling the world.
Working on my products has meant many weekends have been sacrificed.
I’ve worked most evenings during the week and had to reschedule a lot of personal activities around these products. But that’s a sacrifice I’m willing to make. I do not resent my decision. I made a decision to go all in no matter the result.
The willingness to sacrifice cannot be taught.
Which brings me to the fourth and final question.
Question 4: Dare you risk failure?
If you’ve made it this far and you still think you’d like to build a product, there’s one last short question you must ask yourself:
Do you dare to risk failure?
When it comes to building a product, success is simply not guaranteed. You can pour your heart and soul into building something for it to simply fizzle out and die. You have to tread a fine line between knowing when to quit on something that just won’t work and seeing something out to the bitter end.
To be successful you’ve got to imagine a future where it all falls apart, but instead of detering you, it drives you. It drives you to be successful and to work even harder.
For me, building a product hasn’t really been an option. As I said earlier, the goal was to learn how to build my own products because I knew that building a product was my chance to make a difference. It’s something I felt I could excel at, enjoy doing, and have a lasting impact with.
For me, the thought of the regret if I didn’t try far exceeds the fear of failure.
Because, in reality, the real reason to build a product is not just because you can, but because you can’t not.
Not because you want to—but because you need to.
But wait, one last question…
Building a product can seem scary, but my goal isn’t to scare you, it’s to prepare you. You’ll have to sacrifice and accept that you ultimately might fail. But that’s why knowing why you’re doing it and having a team can help.
Being exposed to this experience so far has profoundly changed me. I see the world differently now. I think differently. I see problems as a puzzle to be solved rather than a pain. And all of this experience also comes back with me to my job, making me a considerably more complete programmer.
It’s like running a marathon. We all know running a marathon is hard, but many people around the world every year hit the tarmac. Why? Because they’re masochists? Because they hate themselves? No.
It’s because they know that when it’s all said and done they can say “I did it.” And they know that accomplishing a goal brings satisfaction you simply can’t get from anything other than putting everything you have into an endeavour.
So you’ve asked yourself these four questions. Now there’s only one left:
Do you have what it takes?u
- 2023 Summary: Data Driven Stories About The Cloud - December 31, 2023
- 2022 Summary: The Open Up The Cloud System - January 1, 2023
- Open Up The Cloud Newsletter #30 (January Recap 2022) - March 1, 2022