During my time at Europe’s biggest mid-term rental marketplace, HousingAnywhere. My team had been working on an embedded finance product which we named HousingAnywhere Payments.

HousingAnywhere Payments had been gaining great momentum over the years, with the monthly active user base growing by a factor of 10 in just 2 short years. This growth was attributed to how well it complimented our core product, HousingAnywhere Marketplace, the fact it was free to use, and the quality of the tooling itself.

So what is HousingAnywhere Payments?

HousingAnywhere Payments relieves property managers from the burden of collecting their rental-related expenses from tenants. Instead, leaving HousingAnywhere with such tasks. It would automate things like: calculating the payment amounts, determining the due dates, pulling the money from the tenant when it’s due, notifying all parties if there’s a late payment, and more.

So why weren’t we charging for HousingAnywhere Payments?

HousingAnywhere Payments became one of our most important products during the COVID-19 pandemic. Due to uncertainty with border restrictions, we saw a huge drop in our core product, HousingAnywhere Marketplace. We watched bookings revenue tank because young professionals and students simply weren’t moving internationally during lockdowns. But as we expected, HousingAnywhere Payments didn’t follow the same downtrend that HousingAnywhere Marketplace did. It was clear that those tenants that had already moved before the pandemic still had to pay their rent.

HousingAnywhere Payments became instrumental in continuing our relationship with our main customers, larger property managers. It continued to deliver them value, and kept our account managers busy with them, even though there were no bookings taking place.

But it wasn’t only in tough times that HousingAnywhere payments helped. In the stronger business conditions before and after the pandemic it helped our company gain new customers for our core product, Housing Marketplace. In fact both would feed each other, and the added value helped sales convert new leads across both products.

For all these reasons it had made sense to keep HousingAnywhere Payments as a free product. But we knew we were sitting on something valuable, and charging for the service was the next logical step. The company had invested a lot in the product over the years, and we were absorbing all the transaction fees.

So not long after we’d weathered the COVID-19 storm, and our business was back on track, Senior Leadership decided it was time to finally monetise HousingAnywhere Payments. The announcement was welcomed, but what followed was a lot of confusion. Weeks walked by without any formal delegation of responsibilities, goal setting, or clarity on what was to come next. Teams were confused, and we were all floundering around the idea of monetisation.

All this came at a time when there was a mounting list of responsibilities to work through. Think such as; kickoffs, research, project initiation, and most important of all defining a clear goal.

It wasn’t for some time until we as a company understood the scale of the project and all the teams this touched. This realisation would eventually lead us to our saving grace, our go-to-market strategy, led by one of our colleagues from the marketing team.

With this blog post, I’d like to share some of the things I learned being a part of our go-to-market strategy. I’ll walk through the different phases of work, provide real examples, and provide my key learnings from the experience.

The first and most important thing to establish was why we were Monetising the product in the first place. It may sound like a strange question, but i’ll give you a hint about what’s to come, it wasn’t just about making money.

This was the first step in creating our go-to-market plan. I worked closely with the head of product to get a crystal clear statement of what we were doing and why. It became the foundation to all our subsequent decisions.

Let me set the scene first. Our company had recently secured €24M during a Series C funding round, and this was enough to surely keep the lights for a while, even if revenue dropped to 0. Besides, HousingAnywhere payments wouldn’t bring in much revenue for a long time. Sure, it was growing fast, but it would be years before it would be bringing in enough to cover its own operational costs. So if revenue wasn’t valuable, then why monetise?

Well it had to do with our future funding rounds. We wanted to go for our series D funding, and our pitch would be that much stronger with a newly monetised product line– even with only a few paying customers.

This brought a lot of clarity to the company and things moved quickly from here. I would then work closely with marketing to compile our go-to-market strategy and lay it down on paper, and give all stakeholders free access to it.

So with our clear goal: “prove we could charge money for HousingAnywhere Payments.” We set off creating our strategy document.

The second thing we looked at was the unique number of tenants the property manager sent requests to.

We took all these values, and averaged them on a monthly basis over 6 months. Which ensured we were looking at lasting trends from regular and long-term users. Longevity of usage had to be incorporated in our definition.

We defined “active users” as those that were creating payments for a large number of unique tenants, while also collecting a relatively high amount of money, every month for 6 months.

With the help of the BI team we tabulated these users and sorted them in a table, we could easily compare all property managers to each other, and scoop from the top of the most active accounts.

The final criterion were property managers who average 6 months of

• Creating payments to more than 3 unique tenants
• Collecting more than €8,000

Given the synergies with HousingAnywhere Marketplace, it was no surprise our most active HousingAnywhere Payments accounts were also the most active with HousingAnywhere Marketplace. In fact almost all of them already had big portfolios and a dedicated account manager, who would talk to them almost weekly, often over the phone.

This made it easy to learn more about them, their problems, and how they found our solution, HousingAnywhere Payments.

What did the most active accounts value most about our HousingAnywhere Payments?

We had built up HousingAnywhere Payments over many years, each iteration responding to a new problem we found, and each solution spurring further growth. We had a pretty good idea of what our users found valuable from HousingAnywhere Payments. So we went with a lean approach to further validating value propositions.

I hosted a survey on Slack, asking account managers who had a property manager in the shortlist to vote on what value proposition they felt resonated most with their account.

It became clear the things that were valued the most were

1. Centralising payments
2. Saving time creating payments
3. Lowering trust barriers for their tenants

These value propositions would help us with all our communications moving forward.

How much and when would we charge our customers?

We had to decide when to confront our users with a paywall, and our new newly created definition of an “active user” helped us decide. It had to be related to one of the following criteria:

• Volume of payments transferred
• Number of tenants payments were created for

In order to keep our product freemium, we would need to create a monthly budget for property managers, based on some combination of the two criteria above.

But we were quick to realise the first point can be eliminated relatively quickly. Considering the “volumes of payments transferred” is driven by tenant actions, through them visiting the platform and making payments, there would be no property manager involved, and therefore no property manager on the platform to block with a paywall.

This left the only real opportunity to add a paywall at the tenant selection page. So we would be limiting the “Number of tenants payments were created for”.

When it comes to pricing, we were guided by our goal to simply “prove we could charge money for HousingAnywhere Payments.'' The actual amount we collected wasn’t at all important. So we landed on a low number of €39, which was decided on by senior leadership.

In its ideal state, the product would keep a monthly budget of how many tenants a property manager had sent a payment request to. If their budget of 3 was exceeded, then they’d be confronted with a paywall. The paywall would remain until the customer subscribed to pay the monthly fee, or waited until the new month began.

In order to pull this off, we had a lot of work ahead of us

• Landing page
• Payment page
• Payments architecture
• System emails
• Budgeting architecture
• Admin panel updates
• Subscription management

Due to the volume of work required, there would be a high risk of the project not meeting its timeline. And this risk would have a high negative impact on the project if it eventuated. Almost all teams in the company had something planned around our proposed launch date.

There was also a risk of committing to building the wrong thing. Until we had real paying customers we would be completely guessing on a lot of details of implementation. Besides, why would we put too much effort into something for merely “proving customers were willing to pay”. If the goal was to optimise revenue, we might have considered the risk worth it.

The information above helped us decide to skip the “Budgeting architecture” for now. Instead of an automatic solution, I would manage this with close feedback from sales, a report and a feature flag. I would check the report regularly, and update the feature flag accordingly to turn the paywall off for those specific users who paid.

This lean approach was a game-changer, and the customer didn’t even notice. We lowered the risk by tenfold and only committed resources that were definitely required.

The project went ahead very smoothly, we launched on the proposed date and earned our first 20 paying customers in 2 weeks, we reached our goal!

But here are some things I'd like to reflect on from our go-to-market strategy, and what we could have done better.

Align stakeholders on the agile mindset

When we expressed that the budgeting architecture wouldn’t be built, and that we weren’t sure how it would eventually be implemented in the long term, we had a lot of pushback from other departments, particularly sales. They wanted to provide their accounts certainty as far into the future as possible. It took a long time, and a lot of work, to get everyone on the same page here.

In retrospect, I should have ensured the agile mindset was adopted throughout the organisation early, switching the paradigm from “uncertainty” to “collaboration” with customers. Instead of them being scared of the future, and how we would monetise, we wanted them to be excited in the knowledge that they’d be a part of the decision. If I'd hosted a seminar with all the account managers from the get-go to present this concept, product and sales could have worked together much better.

Make training scalable

Throughout initiation, planning and development, I had a lot of questions. These questions spanned all aspects of the product, and I received the same questions regularly. It took some time before I realised I could scale and optimise this process.

I eventually created a shared FAQ, and shared it with all stakeholders. I allowed anyone in the company to add questions, and I'd fill in the answers, there for everyone to see.

This saved me a lot of time, while also creating a lot of understanding around the product. Also these internal FAQs would give us a headstart on our public FAQs, saving us time in the long run.

Monetise as close to day 1 as possible

The final mistake I think was waiting too long to monetise. Although keeping the product free was beneficial to our organisation. We missed out on a lot of valuable feedback because customers expected less– they weren’t paying so they weren’t critical.

Maybe having hundreds of users not paying is no better than having a handful of users who are paying. Maybe it’s easier to approach customers with the expectation that they’ll need to pay from the first interaction, then bringing it up later.

After All you need to validate that your product is worth something, and the best way to do this is to ask something for it, as early as possible.