How I build internal developer tools inside a small team
There are thousands of resources on how to build good software products. When I was developing my first SaaS product, LemonSpeak, I often found myself in the same loop: Should I implement a new feature or improve an existing one?
The question seems easy - but it isn't. I very often heard people ask how they know if they had reached product market fit. Even I wondered quite a lot. Do you take numbers? Monthly growth rate? For sure, that tells you something. Traction is something you feel and that's the best signal to me. You will recognize a difference in the feedback of your users. More likes, more willing to talk to you, more positive feedback.
The same dilemma returns if you build dev tools inside a company, just with different faces. Instead of customers, your users are coworkers. Instead of growth metrics, you have scattered feedback and coffee corner chats. You are still trying to figure out what to build next.
How to start from scratch for internal dev tooling
There’s a book called The Mom Test. It’s a great resource and I used the principles quite a lot in interviews. The gist is that you should get to the actual problems of a user instead of pitching your solution. Otherwise, most interviewees are too polite and will say: “Sounds good. I'll give it a try”, even though it doesn't help them at all.
I believe, that this process should also be applied internally and repeated continuously:
- You collect problems other engineers and teams encounter
- Prioritise them
That’s your "demand box". If you start on a green field, this and people's opinion is all you have. It's not rocket science. The only caveat is that you need a certain amount of data points to iron out the outliers in your problem clustering. Based on this, you and your team can develop the first service for other developers. Great! But things are getting murky again now. Without further significant signals from your users, it’s difficult to decide what to develop next. The same question arises again: Should you develop the next feature or improve an existing part?
Three axes of boat (product) building
Imagine yourself as a boat builder. If you want to build a boat, you start small with a simple dinghy. Then, you want to make it wider to carry more load. As you add planks, you realise that the boat is becoming too chunky and unstable under the extra weight. To stabilise the boat, you need to deepen the hull. Now we have two axes: width and depth (x and y).
Now imagine the software you are building as a boat. There are two dimensions that you are constantly balancing.
Width & depth
The width in our analogy, is the capabilities or the number of features your product has. That can be an extra functionality, catering more endpoints, or a new piece of UI for your users to interact with the product. That width, however, comes with weight. You add complexity, maintenance, potential friction. You widen the boat - it carries more, but it becomes unstable and more complex to steer.
The depth, on the other hand, means that you improve existing parts of your product. You go deeper in the development for a specific piece. You fix rough edges, increase stability by adding tests, solving bugs, decrease algorithmic time, making it more efficient. That's why I compare it to the depth of the hull of your boat. The depth makes the boat stable.
However, there is a third dimension. When you make the boat wider and deeper, you might experience that even though you can carry more load, drive through deeper water and cater more people, it became slower and more difficult to navigate. You realise that it’s not enough to make it bigger, you also need to add extra sails, a better rudder, and clean up some stuff that would roll around on the deck if it’s getting wild on the ocean.
The preparation dimension
I call this the preparation dimension. The idea is that you prepare your architecture to make changes in the two very tangible dimensions (width & depth).
This is not only refactoring your current approach, even though that can be one part. It’s about setting the right course for your product, to be able to integrate future changes adequately. This is why I compare it to a rudder or a sail. Without those, you still can make changes in the size of the boat, but not as sufficient as it would be with the right sail and rudder.
Here’s a very practical example for a product I am working on: At one point, we realised that we have enough demand to open up the connectivity of our product. We re-thought the current approach as some sort of plugin technology. Now, what I would suggest is that this functionality is going to be prepared by another functionality that you add, either for depth or width. In our case, it was width. That way, a sprint or quarterly planning prepares the next one.
Balancing it.
Having these three dimensions separated helps me tremendously with my mental model of building products. Using the dimensions gives me a tool to define the next steps in a balanced way. Of course, it can also happen that one dimension is put more weight on than another. That can be because you sacrifice speed for technical debt, or because you want to smoke test features to find product market fit, but you make it more transparent for you and the team, and it will be constantly on the radar, that you are building a raft instead of a boat.
With this framework, you can literally ask the following questions during planning:
- Are we widening our product this sprint?
- Are we deepening it?
- Are we preparing it?
It’s OK to focus on one axis more than on another, but I believe they are not independent from each other. At some point, the other axis has to catch up. Now, to build a proper ship, we have to balance these dimensions.
Build and ship in a fast-paced time
Building software products in AI currently comes with a lot of uncertainty. Nobody has a crystal ball to look into the future. Some are more visionary than others, but building products has also a technical, strategical perspective. Building internal dev tools at a company is a mix of demand, what you see in the company, and of future trends. Make sure to talk to devs for which you think the product will be beneficial, and integrate trends when you see a strong signal that it will be helpful to them in an imaginable amount of time. When in doubt of what to build next, another feature or a deeper functionality, take the mental model of the boat building.
🤗✨ If you enjoyed this article, it would mean a lot to me if you shared it on social media or forwarded it to a friend. I write in my spare time, so any support is welcome.