In early October, I gave a presentation on platform thinking at an onsite for Salesloft’s product experience team—what it is and what it enables. The discussion afterward sparked a key realization—while everyone knew delivering quickly was important, many hadn’t fully grasped why speed was so critical.
The presentation was well-received, and I was asked to give it again to close out product all-hands at the end of the month. Given the feedback and the larger audience, I reframed the presentation. This time, the focus was on going FAST. Platform thinking was just a strategy to achieve that speed.
I do believe that going fast is critical for product development teams. It multiplies the opportunities to deliver value to customers and allows teams to learn and iterate quickly. This agility also becomes a competitive advantage against incumbents and better-funded competitors. Building software is a team sport, and when talented people are aligned and focused, great things happen.
I hope y’all enjoy the presentation!
Hey y’all, my name is Sam Solomon. For those of you who I have not met, I’m a staff designer here at Salesloft. I was one of the first designers hired seven and a half years ago.
Currently, I’m in charge of Starlight, our design system. I am also the design lead for our platform pod. That means I work with RNB on Rhapsody, Satellite and a ton of other stuff.
Today, I’d like to talk with you about building software—but you already knew that.
Specifically, I’d like to talk with you about building software FAST.
I’d like to start with a favorite concept of mine—platform thinking.
Platform thinking is the ability to see a system as a whole. It is a viewpoint that helps us see how individual problems and solutions can connect with this larger enity.
It is about viewing this entity as a system, instead of a silo.
We want to avoid silos. They create a dangerous perception of progress, because you’re able to move fast without reconciling how the work you are doing affects the larger system.
It’s a false progress.
In the long run it creates a weaker, more brittle product for our customers, while leaving us with software that’s harder to maintain.
What we want to do is see the big picture.
Designers, PMs, engineers—really anyone on this call would benefit from focusing on the relationship between things instead of the things themselves. Those little connections, instead of the entities.
Parts of any platform don’t exist in isolation. Every feature impacts others—either directly or indirectly. And when you focus only on those pieces, you miss out on the broader implications of how changes in one place affect the entire platform.
So what though?
Yes, we can see how activities and people and tasks are all related. But why is that important?
Because speed is critical. We have to go FAST.
I’ve spent my entire software career asking how we can go faster.
It’s a recurring theme that runs in my head.
Why is speed important?
The simple answer is that the quicker we are able to deliver features the more opportunities we have to deliver value. That’s not unique to Salesloft. That’s true for any software business—probably any business.
Speed gives us options. It gives us the ability to iterate and make decisions faster.
The more complex answer is that speed levels the playing field.
Business-wise Salesloft is, and continues to be more capital-efficient than our competitors. Many of them have raised two to three times as much as we have.
That means they have a pretty large war chest. They have hired talent aggressively, but that also means their cash runway is tightening quickly. High interest rates are an actually an advantage for us in a lot of ways, because it puts them in a much worse position, financially. They have a much harder path to profitability than we do.
And on the product side—speed is our primary weapon to combat better funded competitors.
You can see m diagram here. We’ve got this dot representing value. Then the inner circle is our delivery speed and the outer circle is our competitor’s delivery speed.
The truth is—if we go fast, if we stay on the accelerator—we win.
I don’t get many opportunities to talk about Auburn football these days. So, I’m going to use this opportunity to make an Auburn football analogy.
In 2009, Auburn hired this guy, Gus Malzhan, to be our offensive coordinator. Malzhan, in one year, took Auburn from 110th in total offence—last place—to 17th the next with essentially the same roster. And then in the year after that, 2010, he won a college football national championship.
So in five years this guy went from the head coach of a high school football team, to coaching a college football national championship team. Then he’d take the team to another national championship in 2014.
How does that happen?
The secret was is play style known as the Hurry-up No-Huddle Offense.
Now this approach was the complete opposite of the prevailing gameplay in college football in the late 1990s and 2000s. Teams wanted to hold onto the ball, eat the clock, don’t make mistakes and let defences dominate the game.
Malzhan’s offense looked at the 60 minutes in a football game and tried to squeeze as many offensive plays as possible into those 60 minutes. The team would not huddle if the clock was running, they would work the edges of the field when they needed to stop the clock. When defenses were tired they would take deep shots towards the end zone.
Auburn went from averaging 50 plays per game to more than 90.
And since then virtually every team in college football has adopted some form of the No-Huddle or developed some strategies to contain it. It changed the game of college football.
As we approach the next year, I’d like y’all to be thinking about it as a 60-minute football game. Use platform thinking, use speed—use those thing to give us the most chances to deliver value.
Hopefully, I’ve convinced you that we need to go fast.
What else can help us do that?
Connect the dots.
This stuff is kind of a muscle. You have to exercise it. You have to do the work.
Let’s look at this example—an email task.
Everyone here should be familiar with an email task. It is one of the most heavily used tools in Salesloft.
Given the framework that is built around an email task, we should be able to look at other things and infer how they might work even though we haven’t built them.
What does a text message task look like? Or a Whatsapp message? Or a LinkedIn InMail? These all have similar attributes. They are all text-based asynchronous communication. They should all function similarly. It should be obvious how these other task types might work.
This stuff isn’t magic. A lot of it is boring and straightforward. It just takes focus and effort.
Take what you know about the platform and expose yourself to other features, components and patterns. Talk with others about the same. Do that over and over again and you’ll start to make those connections.
Salesloft is a big platform. It’s really big.
That means there are always new things to discover. I’ve been here seven and a half years and I’m still learning new things.
You know my team, RNB, took over the extension last year. When we took it over, I had no idea how customers were using it. What they were trying to do. Since then I’ve learned a ton.
Along with that, we started helping with the Dialer a few months ago. I thought I knew how the Dialer worked. Man, that product is deceptively complex. I had no idea about the layers of complexity.
If I am finding new things to learn about the product. You certainly can find new things to learn. There’s always going to be something.
Now I’m not going to be prescriptive here. I’m not going to say we need add checklists or introduce a new processes or anything else to take up your time.
You know, because we need to go FAST.
But I want everyone here to be asking themselves these questions when building software. We can save a ton of time by implementing features and components and patterns that we already have.
Can we build this with existing components?
Do similar patterns exist elsewhere?
Does this functionality exist elsewhere?
The worst thing we can be doing in developing software is building features that are 90 percent similar from scratch. Let’s not do that.
Please be asking yourself these things as we work.
The last thing I’d like to leave you with is this idea of individual responsibility with team execution.
None of this will work if it is just me or Leny or Andrii or Christian doing this. We all need to do this as a team.
Let’s stop thinking about building software in silos and let’s start thinking about building a platform.
Let’s go FAST.
Thank y’all for listening!
Comment