Why tools are no guarantee for growth and success

This might sound a bit counterintuitive to write this while I'm building a tool with one purpose – solving a problem. Like I mentioned in here in another blog post:

Processes looked fancy in a book or Medium post. If the company behind the book has 500 or 50.000 employees but you are a team of five, fancy post-its, recurring meetings, and methodologies probably aren’t the right way for you to work.

Only because something works for others, it doesn’t mean the process works for you or your team.

In the past few years, I helped teams shipping products that were in different stages. Some were just introduced to the market, some already existed for ten years. As you can imagine, the process along the way evolved differently. Let’s take the classic double diamond as an example:

Double Diamond (design process model) by British Design Council

Throwing aboard everything the team did before is like tearing a house down because you don’t like the windows. Even if your job is to build and mount windows, you won’t ruin the progress that is there already.

Grow together

Exactly like you alone or as a team together, a process and also the tool have to grow. Adding another tool to your toolchain doesn’t mean you won’t have any problems anymore. A team constantly needs to reflect on the past to learn for the future.

Sprinting without looking back

That’s why one of the essential things Bardo does for you, in fact, is reflecting. In the startup- and business world there is a saying that it’s a marathon, not a sprint.

Unfortunately, most SCRUM/agile teams do exactly that, sprinting without looking back. If you keep running without questioning if it’s still the right thing to do, you miss out on a lot of opportunities. Opportunities to learn and grow and in the worst case, get hurt.

This is how recommendations will look like:

Minimalism in product

I love minimalism and essentialism. One of the core values of minimalism is always reflecting if something still brings value, if it does not, let it go. Now imagine if you add feature after feature with every sprint. Without reflecting if it's still beneficial to your users or the product the only thing you have to do as soon as you can take a breath is fixing things. Or hiring more people just to maintain and build even more stuff.

tl;dr: how you can make sure you still do the right thing:

• pause
• reflect and decide
• let go of steps in a process that don't benefit you or the product
• minimize friction, maintenance, bloat wherever possible

All in all, focus on things that don't scale first!

If this helped you, please consider sharing it. I would also love to hear your thoughts. Let me know in the comments.

I originally shared this post on my blog.