Inside Slickshift: The Next Chapter

Learnings and Observations from a Few Months of Building Slick.

It’s been a while since my last post , mostly because there’s been so much happening at Slickshift, and it’s been taking up most of my focus.

There are some cool developments and insights that I thought would be interesting to share.

Just to recap, my last post about Slickshift began like this: "Slickshift is where technology meets logistics, creating a smoother, more productive world. We're making logistics communication effortless and putting visibility into freight and driver locations at everyone's fingertips. Our goal is to revolutionise communication in logistics just as Slack transformed communication within companies."

The good news is that this is still a pretty accurate definition of what we’re building. We’ve run into many challenges over the last few months, but our core promise remains the same. Fast, transparent communication between drivers, forwarders, and dispatchers, as well as accurate understanding of cargo delivery, is critical for the success of the logistics business. That’s exactly what we’re working on.

Here’s what the last 4 months looked like in numbers:

• Team: 3 amazing engineers joined our team, so we are 7 ppl now

• Users: More than a hundred forwarders and dispatchers are actively using Slickshift.

• Engagement: Hundreds of drivers are being communicated with daily by forwarders and dispatchers through our platform.

• Outreach: We've talked with well over a hundred companies about Slickshift, roughly 30-40% of whom agreed to see a demo, and almost half of them decided to give Slickshift a try.

• Communication: There have been approximately 200,000 messages exchanged on the platform so far.

So, what are the key learnings and observations from this period?

Real customer usage is the ultimate test of any product.

After the MVP of Slick was released, we recognized that we had cut corners in some areas. It’s a natural part of the process. There are two opposing forces at play: one urges you to polish the product and add more features, while the other questions whether you are building something people truly need. There’s also a psychological aspect—it’s always easier to postpone the release and work on yet another thing. However, releasing the product is the only true validation of the work. Is it any good? Do people need it? Are they going to like it?

So, we decided to launch early with just one company on board. We wanted to see if our ideas were even on the right track. Luckily, we quickly saw that our vision of providing a centralized and transparent communication hub, as well as clear fleet status, was on point. However, we also learned that users have high expectations, and the difference between them loving the system or getting frustrated by it is really slim.

Changing established habits is another huge challenge. Generally, people don’t like to switch up things they’re comfortable with. There’s a natural tendency to focus on any evidence that supports sticking to the old ways.

At the beginning, Slick didn’t support message replies. Sometimes notifications about new messages were delayed. The mobile app wasn’t snappy on some devices.

This led to losing a few accounts. While we felt those cancellations were a bit premature, I completely get that people might just be tired of using something that doesn’t work smoothly—and delivering a top-notch product experience is our responsibility.

That’s why we've spent a lot of time over the last few months improving the user experience. 

Our clients have pointed us towards what truly matters—doing a few things well instead of many things halfway. It’s a simple but crucial lesson. As a result of that work, we just received our first five referrals from existing customers—the best sign that people are starting to love the product.

Building a real-time messaging system is no walk in the park.

The technical side of creating our product turned out to be more challenging than we first thought, which, looking back, really makes sense.

The technical brain of our group and the CTO, Mike, has been instrumental. We’ve been teammates since our days at Base, where Mike was one of the first two engineers we hired back in 2010. He stayed on through the acquisition by Zendesk, experiencing firsthand the full evolution of the Base application—from a handful of freelancers to nearly 10,000 companies worldwide, some with over a thousand salespeople. His deep knowledge and experience allow us to experiment and build rapidly.

However, what surprised us most was the sheer amount of effort and the sophisticated quality needed for a real-time messaging system.

Picture this: a driver is nearing their destination and sends a message to the dispatcher, "Which cargo box should I leave the package at?" The message needs to be delivered instantly. The dispatcher quickly replies, but for some reason, there's a slight delay. Perhaps the driver's GPS signal is weak, the office's WiFi lags, or the system itself slows down momentarily. The reason doesn't really matter because the perception for both the dispatcher and the driver is that the app simply doesn’t work. It’s irrelevant that this particular message was sent within 15-20 seconds, because  the dispatcher decided to call the driver and resolved the issue over the phone. It also doesn’t matter that the previous 10 messages were delivered without a hitch. What does matter is that in this specific instance, the system didn’t perform flawlessly, and that's enough to break customer trust.

To prevent such situations, we doubled down on the quality of the core chat experience, ensuring it always works reliably and quickly.

Challenges like this are less apparent when working on products that don’t require 100% real-time functionality. For example, when posting a picture on Instagram or saving a ride on Strava, a delay of a few seconds in appearing on a timeline is hardly noticeable. But for Slick, timing is crucial, and it makes a significant difference.

I think more importantly, we could not face these challenges unless we had early customers using the real system. Decision to release early ensured we could focus on the right things.

The Team is Key

In my last post, I mentioned we were looking for two engineers to join our team.

We definitely believe Ballmer was right on this one.

A key building block of a successful startup is the pace of product development. We're faced with many unknowns, but our vision is clear: we want to create a product loved by thousands of customers. The best way to achieve this, we believe, is to quickly experiment and iterate with our users. And for that, we inherently need engineers.

Thankfully, we've managed to expand our team with three amazing people. It’s pretty remarkable that out of all the options available in the market, these individuals chose to join a very early-stage startup like ours!

Pawel

An AI/ML engineer with extensive experience. Pawel and I worked together along with Alex and Mike (other two co-founders of Slick) for many years at Base and Zendesk. He is an absolute expert in AI and knows how such technology can be leveraged in real-world applications. I’ll share more about our thinking on AI in Business Software, and specifically Slick, in just a bit. However, working with someone who has such a deep understanding of AI has been a fantastic experience.

Piotrek

A Base alumni, Piotrek is deeply product-oriented and loves engineering. For quite some time, we considered working on another idea together but after various attempts, we concluded that building Slick makes the most sense. Piotrek (along with Mike and Alex) was responsible for the whole core experience of the Base product, managed a team of over 30 people, and was my best buddy in product discussions and decisions. It’s been amazing to work with him again, especially now as he finds his passion in being on the edge of technology and building things hands-on. 

Szymon

Szymon is our first hire. I recall from Base that most of the people who ended up being core members of our team were hired in their mid-twenties, with a few years of experience but immense desire and ambition to build things. Szymon fits that description perfectly. After working together for three months, I have no doubts that he is the right person with the right mindset to succeed and build big things.

In terms of work setup we  decided to work remote, with one optional day of working from the coworking space. What’s interesting is that everyone is religiously trying to meet the team in person once a week.

AI

AI is an incredibly hot topic recently. It’s difficult to distinguish the real advancements from the hype. Right now, it seems like every startup is an AI startup. Just a few days ago, Nvidia became the most valuable company in the world—its market cap is around five times the GDP of Poland! Crazy times indeed.

Having observed so many customers at work, we believe that AI will revolutionize the logistics space. When rolling out AI solutions at Slick, gaining the trust of users is paramount. You wouldn’t want to give control over your email to AI, right? As Pawel, our AI lead, says, "It's hard to let go of the steering wheel when you drive your Tesla for the very first time."

So, we take an approach of small steps in the right direction. This strategy has allowed us to deliver a few impressive experiences. For example:

When a driver sends pictures of transport documents to a dispatcher, these are automatically recognized, sorted, and structured in Slick.

When a driver sends a voice message, Slick transcribes it so dispatchers can read the message instead of listening to it, which is sometimes inconvenient.

We also automatically translate messages from other languages.

Even though these functionalities might seem straightforward if you’re familiar with various API endpoints, many people are still pleasantly surprised by them.

However, we believe that in the long term, we need to create an experience—a co-pilot, if you will—that automates and simplifies the many manual tasks currently performed by forwarders and dispatchers. By doing this, people will be able to focus mainly on more interesting, complex tasks, and ensure that routine things are being handled properly. That’s the goal, at least, and we truly believe that’s what the future will look like. We’re pushing hard to launch the first version of our co-pilot-like solution as soon as possible.

Reaching customers

I recently read "Traction: How Any Startup Can Achieve Explosive Customer Growth" by Gabriel Weinberg and Justin Mares. It’s a fantastic book where the authors assert that "Most startups don’t fail because they can’t build a product. Most startups fail because they can’t get traction." To gain traction, a startup needs to find one effective channel to acquire customers—many businesses find none. This realization is sobering.

Gabriel offers a guide to all possible channels (19 of them) that companies can use to acquire customers. He also provides examples of successful companies that have used each of these channels. The task for founders is to test each of these channels and discover which one works best.

One comment that really stuck with me is that founders often assume some things won’t work, either because they haven’t worked in their past experiences, or they are biased because they are not personally excited about them.

Additionally, the most obvious channels that should work for your business are those that worked for similar companies in your space in the past.

In our case, that’s a long-winded way of saying that we should try outbound sales. No one was excited about the idea, as when we’re approached by people via phone, it typically doesn’t end well. On top of that, our previous experiences with outbound sales weren't great.

Having said that, we decided to give it a shot. It’s still not clear if that’s the best channel for us, however, our findings are both positive and surprising.

The biggest surprise is that people in the logistics space are willing to speak with strangers. 85-90% of people don’t hang up the phone while being cold-called. It actually makes perfect sense when you think about it. People just spend a lot of time on the phone with clients, suppliers, drivers. They typically call you back if they can’t pick up the phone. That’s been a positive surprise, as at least we are able to connect with many new potential customers in a reasonable and cheap way. One of our best customers is a company that we just cold-called.

I’m pretty sure that the outbound channel is probably a difficult one in many other industries, however, I’m really glad that it works in logistics and we were humble enough to try it out.

I hope the things I’ve shared here can be helpful or at least give you something to think about.

For me personally getting back to the early startup days and building from the ground up has been really rewarding. There’s something special about working through challenges with great people —definitely something I've missed.

Exciting times ahead 😀