Scalability vs. Pace

Most software startups set out to build a scalable business model and aim to show a high pace in the growth of various key metrics, e.g. ARR. Unfortunately, building for scale and keeping a high pace don’t always go hand in hand.

Do things that don’t scale

Before we get started on the topic of scalability vs. pace I need to provide you with a bit of context for the experiences and learnings listed throughout this text. Therefore I have included a brief intro to the company Unloc, where I have worked for the past couple of years and which is the main source of my reflections on this topic.

The global market for digital locks is booming. This opens up a world of new opportunities for how we manage access to buildings. Or it could, but there are issues. One of the main issues is that many lock systems do not communicate with each other. Unloc is working to solve this by integrating the various lock systems into a simple API, much like what Stripe has done for financial payments. You can read more about Unloc here, but the important “take-away” from this short intro, in the context of this post, is that Unloc is a B2B2C* company and an integrator of several different parties and can thus quickly end up with a lot of external dependencies.

*Reality is a bit more complex as Unloc is not purely B2B2C, but we will assume so for the purpose of this post.

Building a commercial setup rigged for scalability 🚀

Having seen early traction of our product, we set out to build our business model rigged for scalability and growth. In this post, I will focus only on the work we did in relation to our commercial setup as it is (probably) most generalizable across industries.

We went to market as an API-first company, and integrated with various partners, enabling them to use our platform within their own software products. Our hypothesis was that companies in the industries that we serve don’t want yet another system, they would rather add the new functionality to a software or product they already use. We would thus be a new module or feature in an existing system.

Our API approach was driven by the desire to enable others to build great products and services based on our platform and on the perception/belief that we would easier — and more effectively — reach the end-customers through partners who sold their products and services to this mass, rather than us going after each of those independently. These partners had already built a relationship and a level of trust with the end-customers that would take a lot of time for a startup to emulate. Selling through partners naturally meant that we had to share some of our revenue, but that was deemed to be worth it given their commercial reach.

Simplified illustration of Unloc’s early go-to-market setup

In order for our partners to sell our product, which I would place on the early end of the innovation curve at the time, we had to train and educate them on how best to sell it. So we did. We created videos, courses, marketing material ++

We were excited about the setup as the onboarding of a new partner was (more or less) a one-time thing while the revenue they brought in was recurring and required little resources from us. The partners were happy as well since we allowed them to introduce a new product with a recurring revenue stream. So the plan was set: Get more partners and watch the revenue grow. Or so we thought.

The scalable setup is too slow — why? 🐌

We did several integrations with dominant software providers from our target segments, and set up a range of commercial partnerships. We did see revenue starting to grow, but not nearly as much as we had planned / hoped for. The scalable rig was ready, but things were moving way too slowly, why?

There are many variables at play here, but I would point to the following as the most important reasons for the setup not working as intended:

  • Innovative products are difficult to sell through partners
    As mentioned above, our product was at the early end of the innovation curve, which meant that for the vast majority of customers, this was a new product they had never seen or used before. They needed to be convinced and sold on this new product, something which becomes increasingly difficult the further away you move from the actual builders of the product (the startup). You can educate and train partners, but it is difficult to match a startup team’s vision and passion about a product. As the market matures and the product or service becomes more known, it is likely that the value of partnership sales will increase, but in the very early days it can be a challenging route to market.
  • Our top priorities ≠ our partners’ top priorities
    Though we had set up (and still have) some great partnerships, our products will rarely have the same level of priority within our partners’ organizations as they do in our company. An example of this was how quickly we could set up a new integration to get the partner started with our product so they could sell it to the end-customer; we could typically be ready to get to work the next day while our partners first had to run it through various internal processes and evaluate the urgency vs. other projects. Looking back, we might have been a bit naive on this one, as the solution / product we offer is literally all we do, while our partners often have many other products and services to offer. Adding on top of this you have the organizational complexities and politics of larger organizations (most of our partners were larger companies), which can be very difficult to navigate from the outside.
  • Lack of end-customer contact and feedback
    Selling through partners meant lack of interaction with the end-customer. Our product is B2B2C and we ended up focusing mostly on the B2B part and not enough on the B2C part. That is not to say that we didn’t speak with end-customers, we just spent most of our energy on our partners and understanding their needs as they were the ones selling to the end-customer. The fact that we didn’t sell directly to the customer paying for, and using, the product meant that we missed some useful insights and learnings.

A common theme in the points listed above is that in our efforts to build a scalable rig we became overly dependent on external parties for our product to get to market. This meant lack of control and also lack of pace.

The fix 🩹

In order to improve our pace and regain control we set out to reduce external dependencies and the number of steps between us and the end-customer. Paradoxically, we started doing things that do not scale very well. We took control over most of the value chain between us and the end-customer. An example of this was installation of digital locks. We originally didn’t provide lock installations, but for our software to work the customer needs to be up and running with digital locks, which typically requires them being installed. Thus we quickly got dependent on lock installers doing their job in order for us to be able to deliver our product. Not an ideal situation when you want to move fast and be in control.

We still work with a lot of great installation partners but are now also able to do various installations ourselves, which increases our flexibility and pace. Installation of locks is rather labor-intensive work, which is not desirable from a scalability point of view, but it has been necessary in order to get closer to the customer and regain pace.

Similar to the example with the installers listed above, we still work actively with our commercial partners and have faith in this setup for the long term, but now, instead of solely providing an API for partners, we also have our own products that end-customers can start using the same day. We no longer have to wait for a partner to prioritize integrating with us before the end-customer can get started. We can start providing the end-customer with our own products and can then integrate through the partner at a later stage.

Very simply illustrated, we now work with two models:

Simplified illustration of Unloc’s updated go-to-market setup

The results have been clear, our ARR numbers grew more in the 6–8 months after implementing this than what we had seen in the previous 4 years. Of course this might be a bit simplified as many factors are at play when looking at our ARR growth, but reducing external dependencies and taking back control was indeed a key factor.

Learnings 💡

  • You have probably heard this one a thousand times, but as a startup, remember that no one cares more about your company and your products than you do. You are the best at selling your product, so in the early days you should be out there doing it, if not alone, then potentially together with your partners. If you are a B2B2C company (like Unloc), you will miss a lot of important information if you stop at the B2B level and don’t engage with the end-customer.
  • The earlier on the innovation curve your product is, the more in control and in touch with all steps of the value chain you have to be (at least this has been true in our case). When you are part of forming a market there are so many unknowns, so you need to work hard to get enough information to make the most optimal decisions about your strategy and operations. Naturally, all steps of the value chain are important, but I would definitely make sure to prioritize the paying step (the customer), even if you don’t serve them directly, but through partners.
  • If you go for a partnership model be sure to align on incentives, preferably set tangible goals for the collaboration, and contractually binding deadlines. Such a goal-setting process can in itself be highly valuable as it can provide you with information about how much / little the partner thinks of the collaboration and its potential.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store