Software architecture and product market fit
First published at Tuesday, 31 January 2023
Software architecture and product market fit
This is a blog article out of a series where I reflect on what I learned during funding, growing (, and selling) SaaS product companies. While I write those things down for myself, since I believe self-reflection is a crucial learning tool, I also want to share my thoughts with anybody who might be interested. I'm looking forward to your comments on any of these topics. An overview of all related topics can be found below. I have a bunch of these blog posts lined up, so you also might want to follow me if you like this one.
When building a SaaS company the first thing you'll have to do is finding your product market fit, and then you'll have to scale your product. There are many different ideas what exactly product market fit means, but a common theme is: You'll know, because your product will almost sell itself and you usually experience the growth hockey stick (hypergrowth).
On the other hand this naturally means that in the beginning you'll have to adapt your product continuously to what you, your analysts, your researchers, and your colleagues think are the right steps to reach your product market fit. No matter how convinced and well-informed you are while funding your company, reality will be different. This also means to test, learn, and improve very early and not build a green-field project for years without validating it with the right customers.
But what has this to do with your software architecture? When talking about software architecture I mean the services and systems composing the overall infrastructure landscape of your product and not the software design of a single component.
My main take is:
Design your software architecture for modifiability – stay open for change and delay decisions you'd not be able to revert easily as much as possible.
Generally I'd not advise delaying decisions. I consider being able to make sufficiently informed decision as fast as possible one of the main benefits of startups. But sufficiently informed is the key here. While you'll never know 100% or even 90% of what you'd like to know to make a decision when building a start-up, you probably know almost nothing about where the discovery journey of your product will take you. If you'd know this you already right now, you wouldn't be looking for your product market fit anymore.
How to keep software architecture modifiable?
From my point of view, until you really know where your product will go, you should keep your architecture as simple as possible. Even if certain technologies are not 100% optimal for a specific use case, use them as long as they work. Familiarity with the technology is far more important at this stage, since the use case or the usage pattern will probably change anyways.
I'd advise for keeping the number of technologies low and not trying to optimize a technology stack unless it has been proven that a certain part of your product is final (while final never really be final).
You should still try to find bounded contexts. I try to find bounded contexts not from a technical domain perspective, but from a company organizational perspective, because this is most likely less frequent to change. Try to understand your company's go-to-market strategy (even this will also change) and derive scope change frequency from it. Let me use Frontastic as an example:
A simplified view of our product was:
There is a frontend for business/marketing people who should be in control of the contents of their e-commerce website
This always has been the core of our go-to-market philosophy.
There is product data required on any e-commerce site, and we need it fast
Initially we weren't sure if we need to operate a product data replicate ourselves, or if we could use services for this and what kind of service(s) this would be.
There is the actual e-commerce frontend
We always knew that we have to deliver a website, but we were open to the technologies used there and also asked ourselves if other delivery channels would be relevant.
Number 1) always has been the core hypothesis of our go-to-market, and while we have changed our view on 2) and 3) significantly over time while finding our product-market-fit we always wanted 1) to work and never stopped believing in it.
This meant that we put the most effort in bringing 1) to excellence and also knew from the beginning that 1) could be assumed to be the most stable over time. By using proper abstractions we made sure that we could change 2) and 3) over time. We experimented together with customers using alternative implementations and finally stabilized a working product (not "technically" working, all those solutions worked, but from a go-to-market perspective). Once the scope and outside APIs were stabilized we finally were able to also specialize and use less generic technologies to power the now well-defined use-cases and improve our stack's efficiency.
Summary
Understand what parts of your product already have been validated when crafting your software architecture. Allow yourself to use more esoteric and specialized technology for the validated parts but try to use generic and simple architecture for the invalidated parts. Pay close attention to the business development and listen to the departments closer to the customers to know what parts of your architecture are more likely to change in the future. Create interfaces between units derived from an organizational and go-to-market perspective.
Subscribe to updates
There are multiple ways to stay updated with new posts on my blog: