4 lessons learnt launching my first product

Hint: I learned a lot. And I loved every minute.

Bolt CMS v4, the project I’ve worked on for one year now, has just been released. It has been quite a journey involving a lot of learning and dedication (as well as waking up at night with solutions to problems that bothered me during the day). Today, I’m sharing the key lessons and takeaways from launching my first product @ my current employer Two Kings.

Deadlines: we never met them

We delayed the (new version) launch by over 6 months. In retrospect, this is the best decision we made. During that time, we developed more functionality and resolved over 300 (GitHub) issues. You’d think delaying the launch until we’re confident of the product we’re releasing is a bad thing: it was not. Instead of complaining or protesting, our community was fully supportive of what we were doing. At the end of the day, they cared much more about getting a stable product, than rushing buggy software. What we did at the beginning, and throughout, is estimate time and effort for the initial stable release. The point is that we continued treating an estimate as an estimate, and not as a hard deadline.

Side note: we had the luxury of building a new major version, which meant that for the most part people can use the previous stable version during development. But still: estimates are NOT deadlines. (Here’s why)

Key value proposition and quick wins matter

Every successful product has a minimum level of value it has to generate for people to use. That’s why it is a Minimum Viable Product, not an “I installed the dependencies lets go live” product.

With Bolt, the key value proposition for the different users we serve is as follows:

1. For frontend designers¹: simplicity in implementation and flexibility in design
2. For content editors: focus on content and a flat learning curve
3. For developers: powerful and limitless ability to extend and customise

[1] These are the web designers that configure the CMS and develop the website’s front-end.

Having a clear value proposition (what value are we really delivering) made prioritising work and features a no-brainer. But more than that, it helped identify the really key pieces of functionality that an MVP needs. We were counting progress not on a time scale, but on a scale of how much value we generated.

At the same time, what people really hate is when quick fixes are not completed in a short timeframe. If something delivers enough value and is quick to fix/implement, then do it. It’s a tiny amount of extra effort in the grand scheme of things.

Here’s an example of such quick fixes in Bolt CMS:

1. Bulk editing records: mass delete and status updates are common
2. API filter + support for translated values: this initial stable release isn’t about the API, in fact we have API improvements planned down the line. But it took a just few spare hours to make the API sufficient for most use cases already. So no, it didn’t make sense to wait several months to get a few hour’s work that adds this much value.
3. Responsible image extension: like with the API, there’s work planned to allow content editors more control over cropping and resizing images. Whereas we judged that this is out-of-scope for the stable release, it didn’t mean that developing a responsive image extension is: it added enough value at minimal effort, it was a quick fix.

Prioritise stability & maintainability, not the feature factory

Okay I know I just talked about features, but features is not nearly all we did. It won’t be an overstatement to say that a major part of the decision to develop Bolt 4 is to ensure long-term stability and maintainability. In many ways, Bolt 4 was a huge exercise in refactoring — and one worth doing.

Refactoring is undervalued. Don’t fall for that trap.

As developers we all love building new stuff. New stuff is what drives great products. Technical debt is what kills them. (Here’s why)

Justify decisions. But then go together as a team

As a team, we should challenge each other’s decisions, and challenge group decisions: that’s the only way to improve them. So I re-affirmed my view that if I do not agree on a course of action, I should speak out and discuss. Sometimes, we’d change course which is great. Other times, we’d take some other path, but with a thoughtful, justified reasoning why we do what we do. There’s added value in both cases.

In either, we have to go together as a team. So don’t take anything personally, because it is not. Instead, think about what is best for the project.

Thanks. Time to climb new heights.

I want to give a huge shoutout to my manager and mentor Bob den Otter: you’ve been so responsive and supportive over the past several months. Also thanks to Maarten Dalmijn for his encouragement and advice whenever I have PM questions.

With Bolt 4.0 out, it’s time to climb new heights, burn that roadmap and learn new lessons. See you on the way there! 📚