November 30th was my first anniversary on the Factorial product team.
It is my first time at a fast-growing startup and, fellas, has it been a ride so far: I joined as a Product Maker, and 12 months later I find myself working with fifteen product teams.
Before the year ended, I jotted down a quick list of learnings I thought I wanted to keep, and I am now sharing it along with a brief explanation for each of them.
I remember one of the things that gave me energy from the get-go was having access to the same tools and data as the rest of the teams (Sales, CX, Marketing). While for me it was the natural thing to do, and while I had always known the benefits of real-time access to information, seeing it play out on a large operation was fascinating and empowering.
When the whole company knows in real-time what’s the MRR in France, or that story about a customer in Spain, making decisions fast and being aligned around them is so much easier.
With a bit of time, I was happy to learn this transparency didn’t stop at need-to-know business data, but continued with internal policies and processes, such as career paths and salary structure. More importantly, coworkers often made an effort to display the thought process beyond some of those.
Some habits that make things a lot easier when implementing this empowering transparency are documenting in public, working in public, discussing in public, using English as the company language —we’re headquartered in Spain— and, in general, trying to structure things as if you were a bit bigger than you actually are.
With the product team having total access to customers, and using the same tools as Sales, CX or Marketing, I was happy to experience that “research” can happen everyday —it is so easy to qualify and recruit customers to learn from.
Sure enough, with continuous discovery comes the question of the actual depth of insights, and the challenge to operationalize this vast amount of knowledge gathering, analysis and activation.
I like how the simplicity of a classic SaaS organization assigns ownership to different teams:
And I’ve enjoyed learning that, with creativity, this simplicity can be kept (at least at a high level) in a rapidly growing organization.
Talking about simplicity: Factorial grew “from 0 to 1” and “from 1 to 10” without Product Managers.
How?
With great designers interested in having business impact by finding the right problems to solve for actual customers.
Individual contributors who, collaborating with engineers, do lead their own goal-setting, prioritizaiton and end-to-end product building process.
Product leader John Cutler recently wondered where the cracks would form in such an organization. Here’s some of the ones we’re trying to deal with:
When you start a project, and even when you start growing, it’s relatively easy to find areas of focus and shift a whole team towards them when needed.
Say you have the capacity to pursue 3 goals: on a given quarter, you can prioritize a key feature (e.g.: “Messaging”), a specific market (e.g.: “Brazil”), or a whole surface (e.g.: “Mobile app”). The next period, with a new context and new information available, priorities change and teams shift towards them.
The benefits of solving problems fast and learning is well worth the cost of context switching.
However, the organization looks confusing, the code is always new to more people than it would be desirable, and problem knowledge can be lost from period to period.
At some point, you feel the need to build a matrix that provides some clarity and stability. Should the team be organized around stages of the “customer journey”, product features or surfaces, markets…?
We faced this issue and, after a couple of attempts, I learned the obvious: when in doubt, look at customer problems and organize around them.
So we’re now a bunch of “domain teams” that own a set of customer problems end-to-end, like Time management or Payroll. These can often be mistaken by “feature teams”, and we’re trying to be very careful to have the teams’ mission in mind (rather that feature boundaries) when working on each initiative.
So what do these teams look like? Having some rules for how teams should be formed helped us grow our product and engineering team from twenty-something to hundredish.
They aren’t written in stone, but they look something like this:
Shipping requires time for deep work and creativity. Solving problems at scale requires long-term vision, and constant updates in the organization and processes. Here’s how I’ve learnt to manage the mess:
During one of these quarterly revisit to our priorities, we identified an opportunity for a new pricing structure.
Pricing has always been so hard for me: are we leaving money on the table? will customers get angry with the change? Should we start low and then rise prices, or try a higher price and see if it flies?
Not sure if it was due to (false) common wisdom, but I always thought that if you were to deliver the news to customers that you’re pricing was changing, you better delivered them good news. So I thought that, when in doubt, one should set a high price, not leave money on the table, and then react if data showed otherwise.
Turns out there was an angle I was missing, and I was wrong, at least on our context (VC-funded B2B SaaS with uneven product-market fit): if you set too high of a price, you may be placing too high of a barrier for entry, leaving out a lot of people who may find your product helpful, and missing a lot of feedback that can help you increase the value your product delivers.
So if updates to pricing can only go in one direction, it is up.
Start with a pricing you know customers should be comfortable with, and make sure you’re delivering value. Once that is clear, you will be able to confidently ask for more money.
You’ve heard the quote:
Culture eats strategy for breakfast.
While I’ve seen most people agree to it, I haven’t read much on how that translates to actions and what it means at a practical level.
Alignment around a vision, team ownership and agency sound nice to most, but look like a mess in real life: it comes with inconsistent process, incomplete documentation, total flexibility regarding the boundaries of a role, and a constant flow of information between individuals and teams that must have a bias for action.
The ability of a system to adapt to circumstances, thus following a different process and acting differently depending on the information available, sometimes called entropy in management, can provide great results.
But it’s also painful, and not everybody is ready —or eager— to be part of such system.
Which brings me to hiring.
I had done hiring at all levels before, all the way from being part of a hiring team, to hiring manager, through discovering the need for new roles, defining and filling them. However, the importance of hiring at a scale-up stage company was hard to anticipate.
I find learnings on this topic more difficult to synthesize, but I’d like to list a few things I consider important:
My chances of creating the right job description, identifying a good fit, and for them to then succeed increase tremendously when I’ve done the job myself before.
I felt the pain of being a Product Country Manager for France before hiring our first Country Manager, and I felt the pain of dealing with product ops before posting our Product Operations Manager opening (if you’re reading this and feel you’re a good match, please reach out).
This isn’t the first time I worked remotely, but my job at Factorial is the first full remote job I’ve had.
I wasn’t surprised to learn that with the right balance between synchronous and asynchronous collaboration, the right amount of process, and a good communication-through-writing culture, the magic happened.
What I wasn’t expecting is the amount of love I received when we organized an all-company event back in October. Dozens of people who not only knew my name and role, but with whom I had created a bond that we were able to turn into a lot of real, in-person laughs, confidences and general camaraderie.
I used to think that, in a remote team, offsite meet-ups were a great opportunity to work together. I am now convinced the time is best used for developing connections that may go deeper when not talking about work.
Thanks to Jo for her feedback on this article.