Hey, Luca here! Welcome to a 🔒 weekly essay 🔒 from Refactoring.
Every week I write an article to 170K+ engineers about how make good software together, and interview a world-class tech leader. I also build and maintain Tolaria in the open, publishing my workflows and learnings here.
I happen to know many startups who develop B2B products for large companies. I worked in one, invested in another one, and have friends who work in others.
An evergreen problem about these products is organizing work in a way that successfully takes into account:
Roadmap / long-term product strategy
Impromptu requests from key customers
This is tricky from all points of view: business, tech, and team organization. I have thoughts about this, so let’s start from first principles. Really the very basics.
We build tech to solve problems to customers, that pay us in return for it. At any given time we can have many of such customers. Based on this, the type the work we can do to solve such problems lays on a spectrum from bespoke to one-size-fits-all:
100% bespoke — is consultancy work. You just solve the problem, IP is of the client, zero reuse.
100% one-size-fits-all — is product work. You develop features that can be used by all (or many of) the customers of your product.
These types of work are very different but, fortunately, in most real-life situations it’s obvious where your work should land on the spectrum.
First of all, a lot of the ambiguity is cleared up upfront, by deciding the type of business you want to build. Knowing that you want to build an agency vs a B2B SaaS takes a lot of cards off the table:
If you run an agency, the problems you solve change all the time, and there is most often not a clear path to building reusable pieces.
Conversely, if you ran a B2B SaaS with e.g. thousands of customers, any of these customers might want something custom, but it’s obvious that it’s not worth to build it just for them.
About the latter, though, what if these customers are not thousands, but hundreds — or maybe just tens — and each of them is very valuable to you?
That’s where things get messy. Welcome to enterprise B2B SaaS.
So here is the agenda for today:
⚖️ Customer work vs product work — why enterprise B2B creates a unique tension between different types of work, and how you should think about them.
⁉️ Is it worth to do bespoke customer work? — the right questions to ask yourself before committing to custom work for a single customer.
🎽 How to design team structure — use dedicated roles like solution engineers of FDEs to shield your roadmap from customer requests.
📏 How to design tech strategy — empower solution engineers with great platform, so they move fast and build things close to product shape.
🔀 How to converge — treat customer work as validated product input, and create avenues to merge it back over time.
Let’s dive in!
⚖️ Customer work vs product work
If a customer of yours is paying you $100K for a yearly contract, instead of e.g. $2K, and you have, say, only 12 of those customers, all of a sudden their requests, however absurd, look... different.
This customer has leverage — and you have probably spent a lot to acquire them, so it can make complete business sense to do something specific to make them (and only them) happy.
We said this is a spectrum, but for the sake of simplicity let’s call this type of work “customer work“, as opposed to more general “product work“, which is done in the service of everyone.
The problem with customer work vs product work is that they have completely different shapes, when it comes to fundamental factors like:
When and how such work spawns
How urgent it is
How big it is
How it fits your overall strategy
One of the goals of your standard product workflow is to control for these factors, in order to normalize them. So items you plan for are: comparable in size, planned in timely fashion, all fit your strategy, and so on.
Customer work spawns, by definition, from external forces, which makes all of the above out of your control. It also doesn’t land with the same level of discipline that you might put into your product process, so it’s work that is often: urgent, big, and unrelated to your plans.
This leads to questions:
When is it worth to do these things?
How should I design my company accordingly? Speaking of team, tech, and process?
Let’s start with the first one.