How to win even when failing

After being in a full-time role in a company for a long time I’m eager to return to building solo-products. When thinking of what I wanted to achieve I realized that the concept of success was not only about the financial success of the project.

I want to diversify the definition of “winning” - both to not feel like it was all a total failure if sales doesn’t rack up, but also as a mental guide of why I’m building this product.

So, if I hardly get any paying customers at all - how could this feel like a worthwhile endeavor anyway?

Learning a new skill

Typically the recommendation when setting out to build a product is to use whatever stack or technology you are most comfortable with. Usually that is where you are most productive.

Very well aware of this, I decided to do the opposite. Instead of sticking to what I’ve been working with the past couple of years (Node.js, TypeScript, GCP, cloud architecture, Flutter for mobile, etc) I was eager to do something completely different.

I’m building Hue Log as a native macOS application using Swift and the SwiftUI framework. Way back I dabbled with Objective-C for iOS, but otherwise Swift is all new.

My productivity was slow in the beginning. Every thing I tried to make led me down a rabbit hole of even more things to figure out. But I’m starting to gradually feel more and more productive with Swift and SwiftUI (actually it is kind of liberating with an opinionated stack of programming language, framework, toolchain and documentation controlled by the same company).

Taking this productivity hit is a deliberate investment in learning a new skill. Even if Hue Log is a financial disaster, I’ve gained a new skill and will be hitting the ground running whatever iOS or macOS app I would be building after this.

Creative momentum

You can achieve a lot as an organisation, but sometimes as an individual it can feel a bit tedious with every single task having to trickle down through a product management organization, user researched, assigned to a team, made into a story by a product manager, put into a sprint, and so on. Add a bunch of meetings on top of that, and some organizational fires that needs to be put out for good measure.

With building my own solo product my goal is to get back to that short feedback loop again; from idea to implementation all in my own head. The satisfaction of feeling the creative momentum of taking an idea, doing the implementation and basically immediately seeing the result. Iterating until it is good enough, having the whole problem domain in my head without the need to coordinate and align stakeholders.

The feeling of that creative momentum feels like a super-power. Can I get that feeling again it will be all worth it.

Balance the commitment

Despite all the learning and creativity, there is the harsh reality of spending a lot of time on a single thing that may not generate any kind of revenue. Especially when building a rather niche product like Hue Log, that most likely only is relevant for the very geekiest of home automation enthusiasts out there.

My overall strategy is to build more products, so Hue Log is just the start. Put relatively little effort in per product and then double-down on what works.

To achieve this I’ve set out a few rules:

• All effort into up front building; with minimal need to maintain and support after launch (freeing up more time to build the next thing)
• Keep the scope minimal by having the product do one thing well and only that. Only build out more if getting traction and seeing actual user need.
• What-you-see-is-what-you-get-pricing. Don’t convince users by a future roadmap (that I must deliver on) with a subscription, but rather a one-time-purchase.
• Minimal infrastructure to maintain; no SaaS, no backend, leverage AppStore of payments and delivery. Yet again to be able to quickly focus on the next thing if this project is not gaining enough traction.
• Play a long-term game. Given the above rules, it is totally ok if it takes many months, even years, for usage to pick up (since it will require minimal effort keeping the product available). This will also allow for more cost-efficient marketing.

But what if it actually turns out to be a successful product? Am I not leaving cash on the table then?

I’ve thought of that too - and I got a strategy to hedge that. More about that strategy in an upcoming post…