The second week of bootstrapping and building in public is over. But there was not so much ‘building’ in the sense of software building involved so far. I am reaching out to interested people and trying to understand why they are interested in DevOps Metrics, their challenges in managing software development teams, and their job in general.

I talked with the first person about DevOps Metrics. 😃 He is an engineering manager and interested in this topic. I was super nervous beforehand, prepared some questions, and then it was a delightful conversation - at least from my perspective. I concentrated on asking open questions about his challenges and what he or his teams did so far to measure and improve developer productivity. Very important for me was also the motivation behind it, so I always ask Why.

I learned about competitor products that did not work out for him and why. Additionally, I got insights into price sensitivity and potential pricing strategies.

The following steps are:

  • talking to more people
  • structuring my approach further: I am thinking about a template for user research interviews
  • starting to build personas based on the interviews

Something not easy to show here, but I finished the behind-the-scenes work setting up the initial web application: code structure, build system, and first base components like the navigation bar.

Part of the navigation bar

Part of the navigation bar

What you can see in the image is only a part of what I have in mind for DevOps Metrics as the analytics tool for tech organizations. The next steps involve defining the minimum lovable product. Further user research interviews will help for sure.

“Customers don’t just want their needs to be met, they want to be delighted. They don’t just want to use your product, they want to love it.” - productschool.com

Starting with the navigation also showed that I need to write down the whole vision for DevOps Metrics. A bunch of notes across my apartment are not enough.

I don’t want to go too much into detail yet. But some points to highlight:

  • Quantitative analysis is not enough for tech organizations
  • Qualitative aspects combined with quantitative measures are the key for engineering teams and their managers
  • Actionable insights are the most challenging but also most vital aspect

I want to give you a 360-degree view of your engineering department and tech organization.

Last time I wrote about tiny steps. I forgot to mention that you also should practice patience when bootstrapping and starting it as a side-project for the first few months. I don’t feel I make a lot of progress. But, talking to more people about this problem space, setting up the infrastructure, and still being present on social media - that is a lot.

I have ups and downs currently, questioning if it is such a good idea to focus on something that will fail with 90% probability. Because most of the startup and entrepreneur literature is about succeeding companies, I am not primed on the benefits of just doing it. It may fail, but I gather a lot of learnings on the way. At least, that is what I hope.

Let’s face it; this whole endeavor will take months and years. And I am ready for it.

Oh boy, there is competition, plenty of it. Some VC-backed startups and big players are moving into this market as well. It took some days for me to see the good sides of this. It looks like there is a market for tools like DevOps Metrics. Furthermore, I analyzed my competitors a bit, and I am happy to conclude that none of them delivers what DevOps Metrics can do for you.

As a side note, this made me think about product-market-founder fit - a topic I detail out in another blog post.

Day and night, I think about DevOps Metrics. Last week was the first week where I had five days of consulting work with my clients. I still profoundly enjoy this work because my clients are fantastic, and it’s fun to work with them. But is it really what I want to do in the next few months?

I see a big opportunity ahead of me with DevOps Metrics. I can combine more than a decade of experience working in or with tech organizations with my passion for analytics and data-driven decision-making. Additionally, I build a product for the people I work with anyway; and something I want for myself.

So, I decided that I want to end some of my consulting gigs. This will not happen immediately because I don’t like asshole moves and want to give my clients the chance to adapt to ending the collaboration sooner.

Two people already mentioned that even if they had such a tool as DevOps Metrics, much training and coaching would be necessary for their managers and teams to get the most value out of it.

So, I played a bit ‘thoughts ping-pong’ with this idea. Maybe I can start with a conference or meetup talk about the science behind DevOps Metrics.

In the coffee kitchen, we chat about interesting and funny stuff like you would be a co-worker.

The area of artificial life (alife) was one of my main motivations when I started programming. This week I discovered a documentary about one of the earliest alife research projects, called Tierra. It is an adapted VM with a custom assembler language that allows evolutionary patterns to emerge.

For what is this useful? It allows studying organic evolution in digital space, allowing for experiments on a smaller but faster scale. You may think we understood the process of evolution already, but there are still questions open: e.g., the jump to multicellular organisms during the Cambrian Explosion.

The target of most alife simulations is to create emergent complexity. The developed simulation produces more complexity than its rules and programming would allow.

If you want to read further, I highly recommend this article: Open-endedness: The last grand challenge you’ve never heard of

Just build or provide something valuable to someone else. Your business, product, or service does not need to change the world.

I proceed with ‘show, not tell’; and double down my efforts on getting a good UI dummy out of the door. Furthermore, I will follow up with more interested persons. For this, I want to specify a structured template for user research interviews. By this, I should be able to define the minimum lovable product better.

See you next week.

– Felix

Hey, I'm Felix. I share my journey on bootstrapping products and service businesses. Additionally, I write about my learnings in software architecture and tech leadership that I gather during my consulting gigs.
Hey, I'm Felix. I share my journey on bootstrapping products and service businesses. Additionally, I write about my learnings in software architecture and tech leadership that I gather during my consulting gigs.