What I Learned Building RCKRBX 2.0 as CMO and Head of Product

Over the past year, I’ve had the unusual experience of serving as both CMO and Head of Product for RCKRBX, helping rethink a real estate intelligence platform from the ground up.

It has taught me a lot about software. More importantly, it has changed how I think about data, customers and the decisions people make every day.

All the while, AI has been changing the rules as we build.

1.0: Give people the data

RCKRBX 1.0 was built around a fairly common assumption in PropTech: give smart people access to enough good data and they’ll work out what to do with it.

So we gave them data. Lots of it.

The information was valuable, but we were asking users to do much of the heavy lifting. Find what matters. Sort through it. Understand it. Connect the dots. Then translate all of that into a decision.

In retrospect, we were providing intelligence while leaving much of the intelligence gathering to the customer.

When we began thinking about RCKRBX 2.0, we started with a different question. Not: what data can we give people? But: what decisions are they trying to make?

A small distinction on paper. A fairly fundamental one in practice.

2.0: Start with the person sitting in the chair

One of our most important realizations was that there is no single “RCKRBX user”. Where someone sits within a real estate organization changes what they need to know.

• Development: Who should we build for?
• Acquisitions: Who lives here, who is moving here, and does that support our investment thesis?
• Marketing: Who is our highest-value audience and what should we say to them?
• Leasing: Which amenities actually matter to the people we’re trying to attract?
• Ownership: Are our existing tenants happy, and which ones are at risk?

Those questions became much more interesting to me than another dashboard.

Our ambition for 2.0 became to make RCKRBX the best source of decision-making intelligence for each of those people. And once we started looking at the business through that lens, the potential uses for our data expanded considerably.

Real estate has a customer problem

My background is in branding and marketing real estate, so one opportunity was particularly easy for me to see. Most real estate organizations don’t understand their customers the way good consumer companies do.

Consumer businesses spend enormous amounts of time understanding what their customers value, how they behave, what motivates them and why they choose one product over another. Real estate can spend hundreds of millions of dollars creating a product while maintaining a surprisingly incomplete picture of the people expected to occupy it.

We know rents. We know comps. We know absorption. We know construction costs. But ask a team to describe its highest-value customer, not simply their age and income but what they value, how they live, what motivates them and what might make them choose one building over another, and things can become rather less precise.

That looked like an opportunity. Instead of simply giving a marketing team data, why couldn’t RCKRBX turn that intelligence into a briefing document? Who are we trying to attract? What matters to them? Which amenities do they care about? How should we talk to them? What might cause them to choose us over the building down the street?

The underlying data hadn’t necessarily changed. The job we were asking the data to perform had.

Suddenly, the same intelligence became relevant not only to research and development teams, but to marketers, agencies, architects, designers, leasing teams and ownership. That is a much larger table to sit around.

Turning consulting into product

Another lesson came from looking at what our consulting team was already doing well. We had developed ways to survey actual tenants and understand things conventional market data couldn’t tell us. Are your tenants considering leaving? Why? What would make them stay? What would they spend more money on? Which amenities do they genuinely value? And, perhaps most usefully, what are you spending money on that they don’t care about?

Historically, answering those questions required a consulting engagement. With 2.0, we started asking a rather obvious question: why couldn’t every RCKRBX customer do this?

So we began turning a consulting methodology into a product. Users could survey their own customers and understand the attitudes, priorities and intentions of the people already occupying their buildings.

There was an important product lesson in this.

Then AI changed the equation

Like many companies, we initially thought about AI as something you add to software. A copilot. A conversational interface. A cleverer way to interrogate the database. Useful, certainly. But increasingly I think these are the less interesting applications.

AI changes the relationship between the user and the information. RCKRBX 1.0 essentially said: here is the data, go find the answer. 2.0 moved towards: tell us the decision you’re trying to make, and we’ll help you find the answer.

Now we’re beginning to ask whether 2.1 can go considerably further.

2.1: What if we did the work?

Earlier this year I read a Sequoia Capital piece, Services: The New Software, that neatly articulated something we’d already begun circling around. Its premise is straightforward. AI companies might create far more value by selling the work, rather than simply selling the tool used to perform the work. Sequoia describes it as the move from copilot to autopilot.

That distinction has significant implications for where RCKRBX could go next. If 1.0 was “here is the data,” and 2.0 became “here is the intelligence to help you make the decision,” then 2.1 starts to ask: what if we actually did more of the work?

• Instead of providing the tools to research a market, perhaps we deliver the market opportunity analysis.
• Instead of giving a marketing team demographic and psychographic information to interpret, perhaps we deliver the audience strategy and briefing document.
• Instead of showing ownership survey results, perhaps we identify the tenants most at risk, explain why, and recommend where ownership should, and shouldn’t, invest.
• Instead of helping someone analyze which amenities matter, perhaps we deliver the amenity strategy.

It is a fundamentally different product brief. It also begins to blur a line I’ve spent much of my career thinking about: the one between software and consulting. That could be where things get interesting.

From software to outcomes

The traditional SaaS proposition is fairly straightforward. Build a tool. Sell access to it. Train customers to use it. Let them do the work.

AI challenges that arrangement. If we understand the customer’s objective, possess the underlying data, understand the workflow and increasingly have AI capable of performing much of the analysis, why should we stop at providing the tool?

Perhaps the better question is: what outcome did they actually hire us to achieve?

That question is already influencing how we’re thinking about RCKRBX 2.1. Not simply more features. Not another dashboard. And certainly not AI scattered across an existing interface so that we can say the product “has AI”. Something more useful.

That progression might ultimately prove more important than any individual feature we’ve built.

The interface is becoming the question

There is another consequence to all of this. For years, software companies competed by building better interfaces. Better navigation, filters, visualizations, dashboards and reporting. Those things still matter. We spent plenty of time on them in 2.0.

But increasingly I wonder whether the most important interface is simply the question.

• I’m considering acquiring this property. What concerns you?
• We’re developing 300 apartments here. Who should we build for?
• Our leasing has slowed. What are we missing?
• We’re redesigning our amenities. Where should we spend the money?
• Which tenants are at risk of leaving?

The user shouldn’t need to know where the data lives. They shouldn’t need to understand how we’ve organized the software. And they certainly shouldn’t need a training course before they can get value from it. They should be able to arrive with a problem. Good technology should take it from there.

Build around decisions, not features

Perhaps the biggest lesson I’ve taken from building RCKRBX 2.0 is that product development shouldn’t begin with features. It should begin with people and decisions.

• Who is sitting in the chair?
• What are they responsible for?
• What questions land on their desk every morning?
• Which decisions are expensive to get wrong?
• Where are they relying on instinct because they don’t have enough information?
• And where can your data make them smarter?

AI adds one more question: how much of the work required to make that decision can we simply do for them? That’s the question I find myself thinking about most as we look towards 2.1.

The AI capabilities available to us today weren’t available when we started imagining 2.0. What we’ll have a year from now will almost certainly change our thinking again. That’s uncomfortable if your objective is to finish a software product. It’s rather exciting if your objective is to keep building a better one.

My takeaway is simple. Don’t fall in love with the dashboard. Don’t fall in love with the feature. And certainly don’t fall in love with the current version of the technology.