In the following exchange, Compose’s co-founder and CEO, Rami Kalai (@ramikalai), explains how product delivery timelines often promise a frustratingly tidy sense of progression (when actual development involves facing many unknown unknowns) and why they’ve done away with them.
He also details the framework that they follow instead, how they measure the impact of what gets delivered (plus, what’s tricky about gauging Compose’s PMF), and how they’re approaching a historically difficult-to-crack SaaS category.
— The Race Car Method
— The 1-day, 1-week, 1-month lens for deducing scope
— Instrumenting quantitative and qualitative measures
— Differentiating in the ever-demanding inbox space
— Starting with 2 specific, well-defined personas
— Building with intuition as much as customer feedback
The Race Car Method
This most certainly comes from personal experience and, to an extent, personal frustration. If you ask any engineering team, what is the biggest point of conflict for them, they’d all agree that it concerns timelines.
A management team might always say, “oh, these engineers can never stick to dates,” and the engineering managers will tell you, “oh, this management doesn’t understand how software works.”
Because engineering has a very different way of looking at delivery. With management teams, there’s typically a Gantt chart or a project schedule with a start date and an end date. It’s pretty concrete whereas with engineering things are never that obvious.
A major contributor to that uncertainty lies in unknown unknowns. Things that you don’t know, you don’t know. Things that skew timelines the most.
And how do you manage them?
You can try and predict unknown unknowns, which is really an impossible task. Not to say, you shouldn’t. You should spend some time upfront planning a project.
But rather than spending all your attention there, it’s just much better to steer your ship in the right direction with smaller steps and faster iteration cycles.
That way, every time you encounter an unknown unknown, you can then navigate over/under/around that obstacle depending on the approach you’ve committed to.
It’s this same conflict I saw in a founders group I was in, someone started talking about agile, and it quickly became one of the most heated conversations we’ve had.
People were arguing about the merits of how to manage a project and what to prioritize and so on. At the end of the day, there’s no clear answer. It’s about what works best for you and your team.
As I noted in a recent blog post, this is an approach that suits us best:
The core problem is engineering timelines and delivery - how do you accurately plan, predict and deliver project milestones?
Our approach at Compose is a somewhat unconventional one, we solve the problem by getting rid of it.
Instead of trying to slap a timeline on every project, task and line of code, we like to use the “Race Car Method” (patent pending).
The race car method has two components:
- The gas pedal: Ensuring your engineers are delivering product value at the highest sustainable rate possible.
- The steering wheel: Ensuring your product roadmap is continuously thought through and updated based on user feedback.
That’s it.
There are now two simple metrics that you can control far more effectively than you can predict timelines for any one project or task.
If you get the gas pedal right, your team can go anywhere, fast. And if you nail the steering wheel, your team can now go to exactly the right place, fast. And that’s what project management in software engineering is all about.
Does it matter exactly when a certain project will finish if you know that you’re taking the shortest path there (effective steering) as fast as possible (pedal to the mettle)?
At the end of the day: Engineering momentum > Accurate timelines.
The Compose team is not that big.
We’re a 9-person team. That’s the whole company. As far as why we’ve set a framework as a foundation this early, I believe, it’s not a matter of: “the team is growing big, we need to set the groundwork for how we want to operate.”
It’s quite the opposite.
The Race Car method works pretty well when you’re a lean, agile team.
It cuts a lot of the bureaucracy from the loop because you’re now less focused on timelines. You’re instead focused on: “let’s just deliver fast and let’s just steer the car in the right direction.”
Regardless of team size (unless it’s just 1 or 2 people), you need to align on how you want to operate, so that you are all pulling in the same direction. It’s important to make sure the entire team works with the same principle. What that specific principle is, is really up to you.
The 1-day, 1-week, 1-month lens for deducing scope
When we’re deciding on what to build next, we have two approaches.
The planning approach and the product approach.
When we wear the product hat we think regardless of constraints, we just focus on what’s the best way to deliver a feature, for instance.
Once we’ve exhausted this exploratory stage, we put on the project hat and think, “okay, well, if we want to deliver the 1-day/1-week/1-month version of this, what will the scope look like for each of those?”
Then we trim that by donning the product hat again, and asking, “is the user getting the right value out of the features with the 1-week scope or something is still amiss?”
Does what we’re shipping at the end of the week make for a coherent feature? Is it usable? If it’s not, then the minimum viable scope isn’t 1 week, it’s perhaps 10 days because, say, you need 3 more things to make it viable.
Or perhaps the scope has something extra, something that can be reduced, so that you can actually deliver it within a 3-day scope.
Everything we take up, goes through this scoping process. There’s that famous saying, a task will take the time that you allocate it. Parkinson’s law.
It’s very, very true when it comes to engineering. You can over-engineer anything. And, equally, you can hack something together, very quickly, and get something out there that might not be robust enough.
So when we look at any project, we always think, do we want to spend 2 weeks delivering this. Or do we want to spend 2 days? If we’re doing so, what can we actually deliver?
Then, at our current team size, we only take on one high impact, big project at a time. Everyone focuses on that. There’s separate time left to tend to the backlog together.
We’ve tried working on more than one thing in parallel and that almost always means we deliver both projects later than if we had approached them sequentially. That’s just the nature of the team; we operate as a squad so this focus works best.
For more context, we have 3 engineers, then 2 or 3 product people between design, product strategy, and product marketing. Once we’ve decided on something impactful, we just go and execute on that one thing. Then we also roll it out and get feedback.
Eventually we want to toggle out of this product impact-focused approach and lean more into stability, performance improvement, and feature improvements more broadly.
Instrumenting quantitative and qualitative measures
In terms of measuring success, we have a combination of quantitative and qualitative feedback.
The typical analytics setup within our product, so we can see how a feature performs. Are users using it? Are they using it the way we intended for it to be used? If they’re not, why not?
There’s some level of information you can extract from that. One thing we now do is for any feature we ship, one of the conditions of the roll out is that analytics are sorted in advance.
Whether it’s a button the user clicks as a part of a new journey, the button should have some form of analytics for us to understand, if it is being used, and in what context.
That’s helpful visibility.
Beyond that, we’ve also been booking these user onboarding calls where we just watch users going through the initial product setup and learning what works and doesn’t work for them in the flow.
If someone is signing up outside of this one-on-one onboarding exercise and we see something interesting in their usage data, we reach out, and say, “you’ve been using X feature quite a lot, can you tell us what you love about it?”
Or vice versa. If there’s a user who has clicked something once and never again, we write to them to inquire and understand what they might have missed.
Taking up one big thing at a time extends to this phase as well. The product team kicks things off, the engineering team takes over next, and then the product/growth team steps in again when you’re actually delivering the feature.
With Compose, the best metric for us to understand if we have product-market fit is long-term retention. It’s bulletproof as far as a PMF metric is concerned.
The tricky part or the unique aspect of Compose when it comes to PMF is that because we sit on top of your email account and on top of your Slack account, you’re not really creating new accounts to get set up.
You’re just connecting your existing accounts. And that’s why retention is a great indicator, if Compose works great, you’re coming back to use Compose to look at your Slack or email or your other tools.
The minute retention drops you’re falling back to the native Gmail client, or to SparkMail or Superhuman or to Slack. That’s really what we measure up against.
Which is, “are we providing enough unique value here where the sum of the parts is actually greater than the individual components?”
And that’s the magic formula for us in terms of product value and product market fit.
Differentiating in the ever-demanding inbox space
The inbox space isn’t a simple one.
But we think that the timing is right for a new approach at the inbox.
And it really stems from an explosion in real-time collaborative tooling. Putting aside the regular inbox, which resides in our emails, there’s been a rapid increase in the number of tools people use to get work done.
Products such as Notion for knowledge sharing. Figma for design. Github. Google suite. Everything is real-time. Everything is collaborative. There’s no more sending a file named V1, getting a V2 back, then sharing a V3, and agreeing on a final, final V7.
All that’s gone.
But this change has meant that there’s now a need for an inbox experience within each of these emerging platforms.
So while Notion’s core product value is in the Notion page and in blocks that one works with, the fact that it’s real time, means that you need an inbox built into it. Because when you and I are collaborating on a document, you need to be informed of my questions and comments.
That’s where the notification center (as many platforms call it) or the inbox comes in. But it quickly becomes a fragmented experience across each of these tools as this isn’t their core value proposition.
Not something they need to have, not really something that their users want or care about. Thus they’re not dedicating much of their product thought towards bettering this part of the software.
You can always turn on email notifications, but that’s just a hack for getting everything into one place and is a subpar experience. Given that email as a protocol was built for plain text and doesn’t play well with dynamic content/live links.
That’s how we see the current environment.
Where Compose enters is that it isn’t just an email client. Email is just one aspect that we cater to, another one is a different major inbox today, Slack.
I must note that I’ll be avoiding the “M” word, that is Microsoft a lot, so all this context is outside the Microsoft ecosystem.
Outside of that world, Slack is really the primary inbox for many teams. Then, you layer on Notion. You layer on GitHub. You layer on Figma. Linear. Loom, maybe. And suddenly, you have to check on all these different spaces.
Superhuman has definitely nailed the general email experience. But we believe that for collaborative teams there’s still a big gap in terms of bridging all their different tools and, specifically, all the communication that happens across them into a single space.
Starting with 2 specific, well-defined personas
To start off, the persona we’re primarily going after are people who work across departments/teams within a company.
They may sit across product and marketing for example. Or product and engineering. A product manager is a prime user for us. Then, engineering managers. Product marketing managers. Anyone whose work is integrated into different teams.
As a result, these people also end up being users of multiple tools, and as teams grow, the tooling starts to multiply. Making the problem more and more aggravated.
Then, another persona, we look at as a core one is someone who is more of a freelancer. We call them polyworkers. People who work on multiple projects with multiple companies at a time. Contractors. Consultants.
Even they have to work with different stacks and then also, to add to the complexity, have multiple accounts for each of the products they use.
That’s where we’re beginning as far as a target market is concerned.
Building with intuition as much as customer feedback
You’re right in suggesting that what we’re proposing is a very new concept. A new approach to inbox management. So there’s a big educational aspect to our work, which is our current focus and isn’t something we’ve solved completely.
The way we’ve been thinking about current iterations is that we need to build the product as innovatively as we want to but at the same time we need to make things truly simple and familiar for our users.
In terms of feedback, especially given the newness of the category, people might be asking for faster horses vs the car. While we’re trying to show them the merits of the car. 
We need to make a lot of gut-instinct decisions as well.
We still obviously devote ourselves to customer feedback and we take it into account, but a big thing that really helps is that we use Compose within our own team.
So we get to dog-food the product, day in and day out.
Initially that meant getting it all working and functional, but today it means answering what is the best way to manage our inboxes across these exploding sets of different tools?
We need to answer that question from a specific ideology, perspective, or approach, whatever one may call it, and then build that out for different groups of users. Essentially living and breathing the method and then translating that into the product.
Related reading from the Relay archives:
— Scribe’s co-founder, Jennifer Smith, on choosing the Kano Model over the RICE framework
— folk’s co-founder, Simo Lemhandez, on shipping high-impact features on a 3-week cadence
— GoSquared’s co-founder, James Gill, on being power users of their own product