Product strategy · Property management
Product strategy for property management, before you build anything
The short answer
Product strategy for a property management company is the work of deciding whether to build at all. It covers which part of your operation the category software genuinely can't hold, whether configuration or a process change closes the gap instead, and what a first release would have to prove. You end with a scoped plan, not a build commitment.
The per-door line on your software bill has grown every time you took on another association or another owner's portfolio, and somebody has finally asked whether you should just build your own. It's a fair question. It's also the wrong one to answer first, because what matters isn't whether you could build. It's which specific part of the operation is worth owning.
The software bill grows with the door count
Take on an association or an owner's portfolio and the software line goes up with it. That's how the category is priced: per unit per month, usually with a floor, plus fees on payments and screening, plus per-seat charges for the people who need access. Most of your costs get diluted as the portfolio grows. This one doesn't.
So operators reach a size where the software stops feeling like a utility and starts feeling like a partner taking a share of every door they win. That's a legitimate reason to look at building. It's a bad reason to build on its own.
A build doesn't remove that cost, it changes its shape. You swap a subscription for hosting, maintenance, security patching, somebody answering when a resident can't log in on a Sunday, and the standing work of keeping up with whatever your system of record changes next. The subscription stops when you stop paying. A build doesn't. Somebody inside your company owns it from launch until the day it's retired, and if you can't name that person now, you don't have a build, you have something that becomes nobody's job in year two.
There's a quick test for whether the bill is really the reason. Would you still want this if the subscription were free? If the answer is no, you're not building a product, you're refinancing a bill. That can be worth doing. Do it on a surface where a swap is genuinely possible, and not on the system your accounting lives in.
The test for which part of the operation is actually yours
Every operator believes their process is different. The belief is usually sincere and almost always beside the point, because the category software was built by watching a great many operators who all believed the same thing. So the question of whether your process is special has no answer you can check.
Replace it with four that do. Run each candidate through all four in order and stop at the first one it fails. Most candidates fail one, and that's what the questions are for.
1. Ask what boards and owners say when they renew
Not what you'd like to be known for. What actually appears in the reason a board moved to you, or the reason one left. Go and read the last few proposals you won and the last exit conversation you had, and look for the candidate in them. If it isn't there, it's table stakes, and table stakes get rented rather than built.
2. Ask whether a competitor could simply buy it
If a management company two towns over could subscribe to something next quarter and put the same result in front of a board, then so can you, and you probably should. A difference that sits on somebody's price list isn't a difference. This question ends most maintenance, screening and listing ideas in about five minutes, which is a good use of five minutes.
3. Ask how often the workaround actually runs
Name the spreadsheet, the shared inbox or the second system your staff keep alongside the main one, then count how often it runs. Per unit per month, per association per meeting cycle, or twice a year at budget time. Frequency multiplied by your door count is what pays for a build's permanent cost. Twice a year almost never does.
4. Ask what it touches
If the honest answer includes the general ledger, trust or reserve funds, owner distributions or year-end reporting, stop there. That isn't a build candidate, it's an integration, and the reason is regulatory rather than technical. How client and trust funds have to be held and reported is set where you operate, so that part follows the rules of your province or state rather than your preferences. Everything outside that line stays in play.
What you can already rent, and where it stops
The category is mature, and that cuts both ways. Something close to what you want almost certainly exists, built by people who have watched more portfolios than you have. It also means the only thing worth measuring is the gap between how you actually run and what the category assumes, because that gap is the entire thing you'd be paying to build.
The gap is real, and it sits in a small number of specific places rather than everywhere at once. Naming them beats another round of arguing about whether your process is unusual. Here's roughly where the line falls for a company managing rental portfolios, community associations, or both.
| Part of the operation | What renting already gets you | Whether the gap is worth building |
|---|---|---|
| General ledger, trust and reserve accounting | A chart of accounts per property or association, bank reconciliation, owner and resident ledgers, and the reports an auditor expects to see | No. This is the system of record and the part that gets examined. Replacing it buys risk rather than difference |
| Resident and owner portal | Payments, statements, documents, a request form, and a look and feel that belongs to the vendor rather than to you | Often yes, and usually the first honest candidate. It's the surface residents judge you by, and the one most likely to be licensed per seat |
| Work orders and vendor coordination | Ticketing, assignment, photos, status, and a maintenance history attached to each unit that an owner can see | Rarely. Triage, scheduling and after-hours dispatch are a crowded market, and subscribing to one beats building one |
| Leasing, listings and screening | Syndication, applications, screening, and the compliance guardrails that come attached to it | No. This is the most standardised part of the category, and it's the part where getting compliance wrong is expensive |
| Board, committee and architectural review work | Document storage, a violations module, a meeting calendar, and somewhere to file approvals | Sometimes. Governing documents differ association by association, so a company running dozens of them carries a process the category models thinly |
| Onboarding a new management contract | Import templates and a migration service, usually sold and priced as a one-off project | Often overlooked and frequently the best candidate. It's your repeated process, it runs every time you grow, and no vendor has any incentive to make it fast |
| Community programming, amenities and resident life | A noticeboard, a document folder, and an events field that nobody fills in | Yes, if that's what you sell. This is where a community-first operator's actual difference lives, and the category treats it as a rounding error |
Rule out the three cheaper answers first
Two of these resolve in weeks. One of them settles the whole question about as often as a build does, which is why they come before any scoping conversation rather than after it.
If any of them closes most of the gap, the strategy work has already paid for itself and the build stops right here. That's a good outcome, and it isn't a rare one.
1. Turn on what you're already paying for
Most operators run a fraction of what their platform does, because a module got skipped at implementation while everyone was busy migrating data, and nobody revisited it. Ask your account manager straight out which modules are on your contract and switched off. Then ask your staff which ones they were ever trained on. The two lists are rarely the same, and the gap between them costs nothing to close.
2. Change the decision, not the software
Some steps survive only because somebody decided something years ago and the reason left with them. A weekly report nobody reads. A second approval on a spend threshold set when the portfolio was a third the size. An exception process that now runs for every association because one board asked for it once. These cost real hours, and no software removes them, because they were never a software problem.
3. Rent one thing instead of building ten
If the gap is a single job, such as inspection capture, after-hours triage, insurance certificate expiry tracking or resident messaging, there's probably a point tool built for exactly that job which will connect to what you already run. It feels like a smaller answer than a platform and it's usually a better one, because you can stop paying for it if it turns out not to work.
Build on top of the system of record, not instead of it
The version of this that goes badly replaces everything at once. New ledger, new portal, new work orders, inside a company that can't afford a bad month-end. The version that works replaces one surface and leaves the accounting exactly where it is.
The operators who have done this and written about it describe building on top rather than instead. Tricon Residential's annual filing for 2022 sets out a proprietary suite of applications the company developed itself, including one for coordinating repairs and maintenance across field personnel, centralised office staff and third-party vendors, and calls the resulting platform difficult to replicate. What that filing does not describe is an operator replacing its own accounting. The value sat in the layer where the operation was genuinely different, and only there.
Whether that shape is available to you gets decided by something unglamorous, and it's worth checking in the first week rather than the sixth. Find out what your platform will let software you own read and write, how often, and what it costs to be allowed. Some products put that behind a partner programme or a separate licence, so read the agreement alongside the API documentation rather than assuming access follows from paying for the product. That answer shapes the design, and sometimes it decides whether the idea is possible at all.
Then settle which system owns which fact, and write it down. The unit register. The owner or resident of record. The balance owed. One system owns each of those and the other one reads it. Two systems that both believe they own a balance will contradict each other in front of a resident, and that's an argument you lose even when your number is the right one.
What to build first, and why it's rarely the impressive thing
Once something is getting built, sequencing quietly decides whether it works. The instinct is to start with what boards and owners will see, because that's the part you can put on a screen at a meeting. It's usually the wrong first move.
The first build should be whichever one removes the most manual work for the people doing that work every day. The small reason is that staff hours are the cost you can actually count. The bigger reason is adoption. An owner-facing feature that staff have to feed by hand gets fed for about six weeks, and then the data behind it goes stale and the feature turns into a liability you have to explain. A staff-facing tool that makes the week shorter gets used without anyone chasing it, and everything owner-facing you build later runs on the data it produces.
There's a calendar version of the same rule. Whatever ships first has to survive your worst stretch of the year, and every operator has one. For a rental portfolio it's turn season, for community associations it's budget and annual meeting season, and for commercial it's usually year-end. Ship ahead of yours, not into it.
You also have an advantage most industries don't, so use it. Your portfolio is already partitioned. Run one building or one association on the new thing for a full cycle while everything else carries on unchanged, decide in advance what result ends the pilot rather than extending it, and let the people in that building tell you what's wrong. They will, inside a week, and in more detail than any workshop was ever going to produce.
What a discovery here actually hands you
Discovery gets sold as a thinking phase, which is why operators resent paying for it separately. Run properly it produces documents, and each one exists because of a specific way this goes wrong. The ones that look most like paperwork are doing the most work.
It's also what makes a fixed number possible. Nobody can commit to a price until the scope is written to the level where both sides would agree on whether a given thing sits inside it. Underspecified scope is where fixed-price work actually goes wrong, and that's a different failure from the one people usually blame fixed pricing for.
It ends with a recommendation, said plainly rather than implied: build this, build a smaller version of it, or don't build. A plan that arrives without one hands the judgment back to the person who went looking for a partner precisely because they didn't have it.
| Artifact | What it actually is | What it prevents |
|---|---|---|
| Door-level cost model | What the current process costs per unit per cycle, and per association per meeting cycle, counted against your real door count rather than an average month | Weighing a build against a feeling instead of against the subscription and the hours it would genuinely replace |
| Integration map | Which facts live where, which direction each one syncs, what your system of record will let you read and write, and on what terms | Designing for six weeks and then discovering the data the product needs isn't available on terms you'd accept |
| Process map with the exceptions in it | How the work runs today at the level of individual steps, including the association that does everything differently and the owner who still wants paper | Scoping the process as it gets described in a management meeting rather than as it runs at the front desk |
| User flows and wireframes for both audiences | Screen by screen paths for residents, owners or board members and for your own staff, including the empty, error and past-due states | Interface decisions getting made silently by whoever happens to write that part of the code |
| Scope document with the exclusions written out | What's included, and in the same detail what is deliberately not, feature by feature | The month-four argument about whether online payments were always meant to be in there |
| Acceptance criteria and a change route | The conditions that make each deliverable done, plus an agreed way to add something later and what adding it does to the timeline | Done becoming a matter of opinion at the end of a phase you have already paid for |
| The named owner and the running cost | Who inside your company owns this after launch, what it takes to keep it running each year, and what happens when your platform changes something upstream | A build that works for a year and then quietly becomes nobody's job |
Worth knowing before you start
Pull your last three software invoices and split the per-door line from the per-transaction fees and the add-on modules. Operators are usually surprised by which one is growing fastest, and it changes what's worth replacing.
Ask your staff which system they open first in the morning and which one they open second. The second one is often the workaround, and the workaround is where the build candidate is hiding.
Do the counting before anyone shows you a screen. Once a board or an owner has seen an interface, the meeting is about the interface, and the cheaper answers stop getting a fair hearing.
When you ask a vendor about API access, ask three things in one message: what you can read, what you can write, and what it costs to be allowed. A vague answer to the third one is itself an answer.
Pilot on one building or one association, not on a cross-section of the portfolio. A cross-section spreads the pain thin enough that nobody complains loudly enough to be useful.
Further reading
Common questions
Artifacts, not a recommendation deck. A map of where your operation genuinely differs from what the category sells, a cost model tied to doors rather than to a licence, an integration map naming what your platform will and won't let software you own read and write, flows for both the resident side and the staff side, and a scope with the exclusions written down. You should be able to take that to another firm and get a comparable number.
Cheaper than what, over how long, is the question underneath that one. A build swaps a subscription for a different standing cost: hosting, maintenance, support when a resident can't log in, and the work of keeping up when your platform changes something upstream. Sometimes the trade is worth making, particularly on a portal licensed per seat. It's only worth making if you've counted the ongoing side honestly and named the person who owns it.
Usually, and that's the shape we'd normally recommend. Keep the back-office system running operations and build the surface on top of it. What decides whether it's possible is what your platform will let an outside application read and write, how often, and on what commercial terms. Ask that in week one, because the answer changes the design rather than only the timeline.
Somebody inside your company has to, and naming them before you start is part of the decision rather than an afterthought. On our side, most engagements carry on past launch as an ongoing arrangement rather than ending at go-live, because a surface built on a system you don't control needs somebody still paying attention a year later.
Then that's the deliverable, with the reasoning and whatever the cheaper answer turned out to be. Usually it's a module you're already paying for, a process decision nobody has revisited since the portfolio was half the size, or a point tool that does the one job. Some companies take the plan to a team they already work with, and that's a fine outcome too. Finding this out now costs a great deal less than finding it out after a quarter of development.
Weeks rather than months for one operation in one company. Two people matter most: someone with the authority to settle a scope question on the spot, and the person who actually performs the process day to day. The second one is who gets left out, and they're the one who knows which exceptions happen weekly rather than once a year. The calendar constraint is yours rather than ours, so plan around budget season and year-end.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.