Post Product Market Fit - Open Engineering Strategy
When Product Stage Evolves but Engineering doesn't
This post is special for me, it’s the first post about #OpenEngineeringStrategy that I do in collaboration! I love seeing people joining this Open Engineering Strategy movement 😊🥳
Miguel Ángel and I have been in touch after I published several posts on Engineering Strategy and wondered if someone would like to attend a Workshop about it.
We chatted so l could understand better his workshop expectations. We were able to exchange some ideas and thoughts about our experiences in Engineering Strategy. I loved that conversation! We both faced similar situations and we were lost as everyone else in this field :D
Last week, we chatted about the current situation he is facing at Qatium, and how to drive an Engineering Strategy from there.
Miguel Ángel came with a deep analysis of the current situation, the company pains, the developer pains, where the product is, and how engineering is facing some challenges to adapt to the new product reality. I can tell that a meaningful reflection was made before the call, I played a rubber duck/facilitator role in that conversation.
Qatium is a water management platform that allows water utilities to improve their water network performance. Clearly speaking, we help water companies to reduce the water and energy that is lost on the way from the supply to the tap. If you are curious you can find more information at qatium.com
Which is the High-Stake Problem?
The product/business found the market fit and started moving to a prepare for scale phase while the engineering stayed approaching solutions with the market-fit mindset.
We identified the need to adapt the dev team mindset to the new
We decided to go for a classical strategy analysis as explained in the book good strategy/bad strategy, where the first step y stop and listen to what is happening in the organization, collect facts, and refine into insights
After a few weeks of collecting facts, these are a few samples of what we saw. Nothing special or different from other organizations as you see.
Integration tests are too slow
An increasing number of bugs
Increasing cognitive load
A pile of architectural debt accumulated
Large lead time in features without uncertainty
Performance problems in different areas
Thinking about the whole range of facts is what led us to discover the high stake problem. The high stake is no more than a scientific hypothesis, so let’s go and test it
Our hypothesis was that the code was working for seeking a market fit, which means that the code is prepared for accepting features not related to each other and with a high degree of uncertainty. Once we started developing cohesive features and receiving more load is when we started with the problems. Inspired by the techniques described in Strategic Monolith and microservices we decided to plan a Context Remapping. That was new for us because seeking product-market fit leaves little space to actually sit down and think which are the best next features, the fact is you don’t know.
Now with a clear direction for the product we could actually anticipate and plan the system for specific extensions, anticipate performance problems, and even reduce the cognitive load by applying the Inverse Conway Manoeuvre.
This was one of the diagrams we used to remap the context. There is no secret to showing how to structure the code, that should match our roadmap, that by the way is open: https://qatium.com/roadmap/
With a direction present, it is time for describing actions. Through small daily efforts, we should be able to test if our hypothesis was correct or not in a short period of time.
Can I participate in the Open Engineering Strategies?
Yes! I started a section about this at github.com/aleixmorgadas/awesome-engineering-strategy#open-engineering-strategies 🥳
If you want me to help you and co-author a post here, let me know at:
twitter.com/aleixmorgadas, DMs are open or